# Did Y2K Account for the unLeap Year?

**URL:** <https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458>\
**Category:** Factual Questions\
**Created:** [August 30, 2016, 3:20am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458 "2016-08-30T03:20:03Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jinx](https://avatars.discourse-cdn.com/v4/letter/j/c6cbf5/32.png) [@Jinx](https://boards.straightdope.com/u/Jinx)\
**Post date:** [August 30, 2016, 3:20am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/1 "2016-08-30T03:20:03Z")

</div>

We won’t be around to see the panic if I found a loophole, but did the Y2K bug adjustment account for future century years that SHOULD be leap years by conventional wisdom, but WON’T be leap years by the book? Is this yet another little time bomb awaiting to reek havoc in the streets of our self-driving car (or, flying car) future? :eek:

---

<div class="post-metadata">

**Author:** ![UncleRojelio](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/unclerojelio/32/3160_2.png) [@UncleRojelio](https://boards.straightdope.com/u/UncleRojelio)\
**Post date:** [August 30, 2016, 3:25am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/2 "2016-08-30T03:25:33Z")

</div>

```auto

def leapyr(n):
    if n % 400 == 0:
        return True
    if n % 100 == 0:
        return False
    if n % 4 == 0:
        return True
    else:
        return False

```

Probably.

---

<div class="post-metadata">

**Author:** ![Jinx](https://avatars.discourse-cdn.com/v4/letter/j/c6cbf5/32.png) [@Jinx](https://boards.straightdope.com/u/Jinx)\
**Post date:** [August 30, 2016, 3:28am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/3 "2016-08-30T03:28:26Z")

</div>

OK, but how about the subtle shift in time between Epochs? 😉

---

<div class="post-metadata">

**Author:** ![watchwolf49](https://avatars.discourse-cdn.com/v4/letter/w/e9c0ed/32.png) [@watchwolf49](https://boards.straightdope.com/u/watchwolf49)\
**Post date:** [August 30, 2016, 3:35am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/4 "2016-08-30T03:35:30Z")

</div>

Actually, the _ **real** _ date the all of civilization comes crashing down is January 19th, 2038 … a fairly good chunk of us should be still alive.

From Wikipedia: “The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 (“the epoch”).[1] Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the “Y2K problem” (also known as the “Millennium Bug”), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this “Unix time” format, so the year 2038 problem is sometimes referred to as the “Unix Millennium Bug” by association.”

---

<div class="post-metadata">

**Author:** ![UncleRojelio](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/unclerojelio/32/3160_2.png) [@UncleRojelio](https://boards.straightdope.com/u/UncleRojelio)\
**Post date:** [August 30, 2016, 3:37am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/5 "2016-08-30T03:37:44Z")

</div>

> [@Jinx](#):
>
> OK, but how about the subtle shift in time between Epochs? 😉

Leap seconds are routinely added by the USNO without serious side effects.

> **[Leap second](https://en.m.wikipedia.org/wiki/Leap_second)**
>
> A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC), to accommodate the difference between precise time (International Atomic Time (TAI), as measured by atomic clocks) and imprecise observed solar time (UT1), which varies due to irregularities and long-term slowdown in the Earth's rotation. The UTC time standard, widely used for international timekeeping and as the reference for civil time in most countries, uses TAI and consequently would r...

---

<div class="post-metadata">

**Author:** ![Keeve](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@Keeve](https://boards.straightdope.com/u/Keeve)\
**Post date:** [August 30, 2016, 10:21am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/6 "2016-08-30T10:21:26Z")

</div>

> [@Jinx](#):
>
> … did the Y2K bug adjustment account for …

You are making a fundamental error. You presume that there was one single adjustment, and you are thus quite reasonably wondering what was included in that repair.

That’s not how it worked. Every single program and device has its own way of dealing with dates, and so each one needed its own fix. For example, the Microsoft Excel program on my desktop needs to be able to sort a list of dates, and it has to know that 12/15/99 is older than 01/08/00. The mainframe that produces my bank statement each month also needs to sort such dates, but it will be done in a different way by a different program, and will therefore need a different Y2K fix.

Side comment for anyone who doesn’t know what the OP means by “unLeap Year”: 1600, 2000, and 2400 are evenly divisible by 4, so you would think that they are leap years, but they are not. Computers need to know this, for at least two situations: (1) They should not accept “02/29/2000” as a valid date if someone types it in. (2) They need to ignore that date when counting the days between two dates. Both of these situations are different from the problem of sorting dates properly, and therefore it is quite possible that someone’s Y2K fix handled some of these but not others. I hope the casual reader is starting to get a sense of what a mess this was, from the programmer’s perspective.

---

<div class="post-metadata">

**Author:** ![chrisk](https://avatars.discourse-cdn.com/v4/letter/c/6de8d8/32.png) [@chrisk](https://boards.straightdope.com/u/chrisk)\
**Post date:** [August 30, 2016, 10:35am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/7 "2016-08-30T10:35:34Z")

</div>

> [@Keeve](#):
>
> Side comment for anyone who doesn’t know what the OP means by “unLeap Year”: 1600, 2000, and 2400 are evenly divisible by 4, so you would think that they are leap years, but they are not.

No, **UncleRojelio’s** code sample is correct; 1600 and 2000 were both leap years, and 2400 will be if we’re on the same calendar system, because the number of centuries is still a multiple of 4. However, 1700, 1800, and 1900 were not, and 2100 won’t be.

“02/29/2000” is not only a valid date, but apparently a noteworthy date in this account of the [Second Chechen War](https://en.wikipedia.org/wiki/Second_Chechen_War).

---

<div class="post-metadata">

**Author:** ![Keeve](https://avatars.discourse-cdn.com/v4/letter/k/f07891/32.png) [@Keeve](https://boards.straightdope.com/u/Keeve)\
**Post date:** [August 30, 2016, 10:41am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/8 "2016-08-30T10:41:10Z")

</div>

> [@chrisk](#):
>
> 1600 and 2000 were both leap years … However, 1700, 1800, and 1900 were not, and 2100 won’t be.

:smack: :smack: :smack: I knew that. But I was typing too fast to think about it. :smack: :smack: :smack:

Thanks.

---

<div class="post-metadata">

**Author:** ![leahcim](https://avatars.discourse-cdn.com/v4/letter/l/b4bc9f/32.png) [@leahcim](https://boards.straightdope.com/u/leahcim)\
**Post date:** [August 30, 2016, 10:54am UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/9 "2016-08-30T10:54:28Z")

</div>

A lot of computer programs use a simplified rule of “all years divisible by 4 are leap years”, omitting the subsequent two clauses, “but years divisible by 100 aren’t” and “but years divisible by 400 are”.

It just so happens that the errors caused by the two omitted clauses cancel out in the only centenial year so far where computerized algorithms are relevant.

---

<div class="post-metadata">

**Author:** ![Pixel\_Dent](https://avatars.discourse-cdn.com/v4/letter/p/bc8723/32.png) [@Pixel\_Dent](https://boards.straightdope.com/u/Pixel_Dent)\
**Post date:** [August 30, 2016, 2:04pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/10 "2016-08-30T14:04:01Z")

</div>

> [@Jinx](#):
>
> We won’t be around to see the panic if I found a loophole, but did the Y2K bug adjustment account for future century years that SHOULD be leap years by conventional wisdom, but WON’T be leap years by the book? Is this yet another little time bomb awaiting to reek havoc in the streets of our self-driving car (or, flying car) future? :eek:

I admit I knowingly wrote code that simply divided by 4 because I did not expect my work to be in use in 2100. If your TV doesn’t record the February 29th, 2100 episode of “CSI: Luna City” you can blame me.

---

<div class="post-metadata">

**Author:** ![septimus](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/septimus/32/410_2.png) [@septimus](https://boards.straightdope.com/u/septimus)\
**Post date:** [August 30, 2016, 2:14pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/11 "2016-08-30T14:14:43Z")

</div>

> [@UncleRojelio](#):
>
> ```auto
> 
> def leapyr(n):
> if n % 400 == 0:
> return True
> if n % 100 == 0:
> return False
> if n % 4 == 0:
> return True
> else:
> return False
> 
> ```
> 
> Probably.

Bloatware. :rolleyes: Why not just  
#define NOTLEAP(Y) (Y%(Y%100?4:400))

---

<div class="post-metadata">

**Author:** ![Amateur\_Barbarian](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Amateur\_Barbarian](https://boards.straightdope.com/u/Amateur_Barbarian)\
**Post date:** [August 30, 2016, 2:22pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/12 "2016-08-30T14:22:04Z")

</div>

I think that thinking intensive global focus on an endemic date computing error would exclude people who know the subtleties of the leap year calculation is a bit of a leap. Just sayin’.

(Our twins were almost born that Feb 29, but things settled down and they waited a few more days to invade planet Earth. I still think that would have been _so_ _damned_ _cool_…)

---

<div class="post-metadata">

**Author:** ![OldGuy](https://avatars.discourse-cdn.com/v4/letter/o/3bc359/32.png) [@OldGuy](https://boards.straightdope.com/u/OldGuy)\
**Post date:** [August 30, 2016, 2:36pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/13 "2016-08-30T14:36:40Z")

</div>

> [@watchwolf49](#):
>
> Actually, the _ **real** _ date the all of civilization comes crashing down is January 19th, 2038 … a fairly good chunk of us should be still alive.
> 
> From Wikipedia: “The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 (“the epoch”).[1] Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the “Y2K problem” (also known as the “Millennium Bug”), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this “Unix time” format, so the year 2038 problem is sometimes referred to as the “Unix Millennium Bug” by association.”

Do they count the actual seconds including leap seconds when added? OR do the assume each day is 60_60_24 seconds?

---

<div class="post-metadata">

**Author:** ![74westy](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/74westy/32/3950_2.png) [@74westy](https://boards.straightdope.com/u/74westy)\
**Post date:** [August 30, 2016, 2:41pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/14 "2016-08-30T14:41:58Z")

</div>

> [@septimus](#):
>
> Bloatware. :rolleyes: Why not just  
> #define NOTLEAP(Y) (Y%(Y%100?4:400))

#define LEAP(Y) !NOTLEAP(Y)

---

<div class="post-metadata">

**Author:** ![markn\_1](https://avatars.discourse-cdn.com/v4/letter/m/f9ae1b/32.png) [@markn\_1](https://boards.straightdope.com/u/markn_1)\
**Post date:** [August 30, 2016, 3:04pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/15 "2016-08-30T15:04:33Z")

</div>

> [@OldGuy](#):
>
> Do they count the actual seconds including leap seconds when added? OR do the assume each day is 60_60_24 seconds?

When added to what? Not sure what you’re asking here. But there have only been 26 leap seconds added since 1972, and there will probably be only a few more by 2038, so they’re not going to significantly affect the actual moment when the Unix time overflows 32 bits.

–Mark

---

<div class="post-metadata">

**Author:** ![pulykamell](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/pulykamell/32/3166_2.png) [@pulykamell](https://boards.straightdope.com/u/pulykamell)\
**Post date:** [August 30, 2016, 3:15pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/16 "2016-08-30T15:15:28Z")

</div>

> [@septimus](#):
>
> Bloatware. :rolleyes: Why not just  
> #define NOTLEAP(Y) (Y%(Y%100?4:400))

You can even save a couple more characters and drive people even more nuts trying to figure out your code and what the hell it means with y%(y%25?4:16).

---

<div class="post-metadata">

**Author:** ![Mangetout](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/mangetout/32/19_2.png) [@Mangetout](https://boards.straightdope.com/u/Mangetout)\
**Post date:** [August 30, 2016, 3:18pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/17 "2016-08-30T15:18:32Z")

</div>

> [@Keeve](#):
>
> That’s not how it worked. Every single program and device has its own way of dealing with dates, and so each one needed its own fix. For example, the Microsoft Excel program on my desktop needs to be able to sort a list of dates, and it has to know that 12/15/99 is older than 01/08/00. The mainframe that produces my bank statement each month also needs to sort such dates, but it will be done in a different way by a different program, and will therefore need a different Y2K fix.

dBase had a Y2K+1 bug. Everything was OK until the point where there had been 101 years in the century (some standards were hardcoded to count from 1900, others from the last year ending 00)

---

<div class="post-metadata">

**Author:** ![Lemur866](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/lemur866/32/434_2.png) [@Lemur866](https://boards.straightdope.com/u/Lemur866)\
**Post date:** [August 30, 2016, 3:28pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/18 "2016-08-30T15:28:08Z")

</div>

I hope they also fixed the Y10K bug, or all those systems are going to spit out the wrong results in 10,000 AD. They hard-coded that the year could only have 4 digits? YOU MANIACS! YOU BLEW IT UP! AH, DAMN YOU! GOD DAMN YOU ALL TO HELL!

---

<div class="post-metadata">

**Author:** ![Amateur\_Barbarian](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Amateur\_Barbarian](https://boards.straightdope.com/u/Amateur_Barbarian)\
**Post date:** [August 30, 2016, 3:35pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/19 "2016-08-30T15:35:10Z")

</div>

Professor: “…and so our sun can be expected to burn out in about fifty million years.”  
Dozing Student: “What? How many years?”  
Prof: “About fifty million.”  
Dozer: “Oh, thank god. I thought you said \*fifteen \*million.”

---

<div class="post-metadata">

**Author:** ![watchwolf49](https://avatars.discourse-cdn.com/v4/letter/w/e9c0ed/32.png) [@watchwolf49](https://boards.straightdope.com/u/watchwolf49)\
**Post date:** [August 30, 2016, 4:53pm UTC](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458/20 "2016-08-30T16:53:40Z")

</div>

> [@OldGuy](#):
>
> Do they count the actual seconds including leap seconds when added? OR do the assume each day is 60_60_24 seconds?

Yes … good point … a quickie search and I came up with timestamp just repeating the final second of the day leap second is imposed. Then a table is maintained of each leap second and consulted when time calculations are required. This is a problem since this table has to be updated every time there’s a leap second and that isn’t always practical. This means your coffee-maker will detonate a few seconds before the end of the world. Maybe this is a feature, gives everyone a chance to kiss their sweet ass goodbye …

[Next page](https://boards.straightdope.com/t/did-y2k-account-for-the-unleap-year/764458.md?page=2)