Time changes man; man changes time.

Because of a project I was involved with over a decade ago, I have an abiding interest in the algorithms and heuristics people use to tell time and dates on computers.  [It’s also why we didn’t have any Y2K issues with WFTPD and WFTPD Pro, although we will have Y2K36 issues]

Every so often someone will ask me why computers can’t get times and dates right.

The biggest reason is that time is relative.  Even if you’re not talking about General Relativity effects, where your acceleration or local gravity affects the relative speed with which time travels, there’s the simple issue that the clock inside your computer is not running at quite the same speed as the clock inside mine.

But that’s okay.  The time setting is allowed to drift – the software in your system allows for adjustment of the clock either manually, or by reference to an external source, and most network applications that care to know about time expect that the two ends of a network connection may differ by several seconds, maybe even minutes, if they are not required to be synchronised with a central time source.

Those applications that are required to keep historical information have a different challenge – you see, a date has to contain information not only about when it was, but where it was as well.  George Washington’s birthday and age are often specified rather vaguely, because he was born just before the date (February 1752 – March 1753) when Britain and her territories changed from the Julian calendar to the modern Gregorian calendar.  This brought our modern leap-day system into effect in those countries, and since the rest of Europe had already been on the Gregorian calendar for several years, we had eleven days to catch up.  There were some interesting issues there (for instance, let’s say you get paid on a daily basis, but your landlord expects a full month’s rent for the month), even some riots with people demanding their eleven days back.  Oh, and the beginning of the year changed from March to January, just to make things even more confusing.

“I’m glad we don’t have to deal with that kind of thing these days”, you might say.  Oh, but we do.  Every year, various parts of the world artificially advance and retire the time by an hour.  When they do it is more or less random.  Where they do it is more or less random.

The proper answer to all of this should be that we keep all our times and dates in UTC, the Universal Coordinated Time zone, which more or less coincides with GMT, and that we use an offset from that to declare where we are right now, and to show times to people.  It still amazes me when I see programmers missing this obvious step.  It leads to some horrible errors in calculation, which often need to be manually corrected for.  I once had a flight that arrived during the repeated hour on an autumnal daylight saving time change, and because arrival and departure times are printed and displayed in local time format, I had no way to tell how long my flight was, or how much time I had till my connection.

This sort of confusion doesn’t occur very often, but those are just the kinds of bugs that leave users scratching their heads.

Leave a Reply

Your email address will not be published. Required fields are marked *