Y2K: Setting The Record Straight

Y2K came and airplanes didn’t fall out of the sky, nuclear reactors didn’t blow up, and society didn’t fall apart. So it was all a scam by programmers to make money, right?

First off, early Y2K bugs showed up in the 80s, when inmates were released prematurely because their scheduled release date rolled into the new century, but it overflowed. But that stupid COBOLism is really just a simplification for all the non-programmers. Let me explain how complicated time is.

We have 60 seconds per minute, and 60 seconds per hour. However, there’s only 24 hours per day; still, it’s fixed—unlike days/month, which varies between 28 and 31, and can’t even stay the same year to year: February is 28 days, unless it’s divisible by 4, unless it’s also divisible by 100, unless it’s also divisible by 400. Year 2000 would normally be a leap year, except it wasn’t supposed to be, except it really was when it wasn’t supposed to be. By luck of timing, we hit a century where getting it double wrong meant it worked right.

So now, suppose you want to know how long it is from 10:30 to 2:30. Did you mean AM and PM then? Because depending on your culture, you may use 12-hour or 24-hour time. So it’s 4 hours from 10:30 to 14:30… if you assume they’re in the same time zone. Are they? Because when that piece of e-mail arrives that somebody sent at 14:30, you might read it at 10:30 if they’re in Atlantic and you’re in Pacific time zone. The software has to figure that out. If it arrived in Mountain time at 10:30, it would be 12:30 in Eastern, but maybe not in Arizona which is Mountain time but doesn’t change the clocks for daylight savings, in which case date needs to be considered. And what if you don’t know the time zone? It can be inferred from your IP address, but is that wise?

But if we know the time zones, or can infer them, we can calculate how long it is between 10:30 and 14:30. Which is not so easy from 22:30 (10:30pm) to 02:30 (02:30am) the next day, because when I said there were always 24 hours/day, I lied. On top of all that nonsense of timezones, two days a year the goddamn time switches between standard and daylight time, if you’re in one of the places they do that sort of thing. And just to keep it interesting, what 2 days a year it happens isn’t the same in all places. And for extra credit, governments like to periodically mix things up and change the dates for daylight/standard time changeovers.

And the date isn’t much better. The US prefers June 5, 2014 or 6/5/2014. But some US citizens like dashes, so 6–5–2014, which is also what many Europeans like, except they would write 5–6–2014. So when you see 6–5–2014, does that mean June 5, or 6 May? As a bonus, Asians often put the year first, so 2014–05–06. Thankfully, it’s always year-month day, and it’s easily detected… except for the first 31 years of a century if the date is written with an abbreviated year: 14–05–06. Is that May 14, 2006, 2014-May-06. At least we can tell 14 isn’t a month, but for 12 years that was a problem too.

Durations are horrendous too. Imagine something that runs one afternoon from 3 to 6PM, and something that runs September 23rd through the 25th. The duration of the afternoon event is easily calculated as 6–3 = hours, so the other runs 25–23 = 2 days? Nope. We speak time as half-open ranges, but dates as inclusive ranges, so the 23rd through the 25th is 3 days.

An obvious solution to this problem is to store everything as a time using half-open ranges, converting to humanspeak on input and output. The aforementioned date range could be stored as 1999/09/23 00:00 through 1999/09/26 00:00. Except you now you’re using a time, which is subject to time zones when you might not mean it to be. Suppose the the date range was a worldwide holiday for some religion: you set the dates in your time zone, then try to show them for someone somewhere else and they show up wrong because the start and end times will change. You really do need time-free dates separate from dates with times.

So when you think Y2K was a nothing, just a bunch of smoke and mirrors hiding a cash cow, think again. Yes, there was probably exaggeration by the media regarding the potential fallout. But a lot of Y2K effort was replacing simple code that didn’t reflect the complexity of time, a long-lurking problem needed to be delt with. Writing new code that manipulates time correctly, as simple as it sounds on the surface, was not so easy when looking into the details. And even with all that work, manipulating dates and time continues to be ugly.