Writing

Feed Software, technology, sysadmin war stories, and more.

Friday, May 25, 2012

A leap year's parting gifts

As long as I'm writing about years, I might as well throw out some other things about times and dates.

I hope that everyone is aware that 2012 is a leap year. Yes, I realize that February 29th already went by, but that's not the end of the fun. You might think that your software managed to handle that and so everything is fine. You might be wrong.

Leap years have a final stinger which doesn't strike until their very last day. On that day, December 31st, you get to experience "day 366". Most systems don't notice and don't care, since they don't think about time that way. However, every four years, there's always something which comes up. Someone does something wrong, and New Year's Eve turns into Groundhog Day -- that is, it keeps repeating.

So okay, you figure out that a year might have 365 or 366 days, and you survive that somehow. Here's my next challenge: how many hours are in a day? You might be right if you said 24, and you might be wrong. Again, it's all in how you look at things.

If you live in one of the time zones which does a daylight saving or summer time flip twice a year, then you have days with 23 or 25 hours as well. If you have systems which happen to run on local time, then they will also experience it.

You might think that your systems are immune to this little bit of wackiness because they run on UTC internally and just display local time to humans. Just about anything which is Unix-flavored probably matches this description. Okay, so that's your kernel... but what about your userspace programs?

I bet your cron jobs run based on local time. Have you scheduled anything that's supposed to run between 2 AM and 3 AM? One day a year, that job will not run, because in local time, that hour never happens. How about jobs between 1 AM and 2 AM? One day a year, they might run twice.

This is old news to many people, and I'm sure they've already tired of this post, but it bears repeating because it just keeps happening. Time and date handling is difficult. There's no way around it.

Just for completeness, I will mention that not all days have 86400 seconds depending on your point of view due to leap seconds, but that gets even more interesting. There has been plenty written about UTC vs. UT1, keeping or ditching leap seconds, and the whole idea of "smearing" it out so systems don't hit the same time twice. I won't try to duplicate it here.

Think back a few years here for some more time-related breakage. How many people had to forcibly upgrade their KDE installations back in 2001? On September 8, 2001, time_t rolled over to 1000000000 seconds. Adding that extra place broke whatever version of KDE's mail client was installed on a machine I had built for my parents. The fix would have involved upgrading the whole stack, since apparently there was no patch to just the mail client.

It seems they had designed their mail storage format to use the text-based representation of time, and somehow managed to make it care about character positions in the file. So, when it got wider by one more character, everything else on the line was offset, and everything broke.

If you had to point to a time when I gave up on "Linux on the desktop" for normal people, that would be it. Granted, three days later, the whole country had bigger things to worry about, but things eventually circled back to not being able to do e-mail on that machine. A couple of weeks later, I purchased the family's first iMac. It was small, cute, and it actually worked. It's been like that ever since.

Finally, it occurs to me that in 2012, there are people alive now who will still be alive when 2100 rolls around. I'm sure there will be some epic flame wars and failures involving "is it a leap year or not" by then. Given humanity's past computerized handling of timekeeping, I imagine it will be quite a show.