Synthesis Studios

This is a surprisingly difficult question to answer. The standard advice is just to store everything as milliseconds since the epoch (January 1st, 1970) in UTC, but this breaks down as soon as you need to show a time to a person or get one from them.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong:

• not every day has 24 hours (e.g. March 11, 2007 and November 4, 2007 — in most of the United States, at least)
• some times never occur (e.g. 2:30 am on March 11, 2007)
• some times occur twice (e.g. 2:30 am on November 4, 2007)

If you go further back in time, things get even worse:

• entire days don’t exist (October 5 to 14, 1582 in Spain, Portugal, and most of Italy)
• the calendars of different countries may be days or weeks apart, and change depending on the year, as illustrated in this quote from Vladimir Nabokov (born in Russia):

All dates are given in the New Style: we lagged twelve days behind the rest of the civilized world in the nineteenth century, and thirteen in the beginning of the twentieth. By the Old Style I was born on April 10, at daybreak, in the last year of the last century, and that was (if I could have been whisked across the border at once) April 22 in, say, Germany; but since all my birthdays were celebrated, with diminishing pomp, in the twentieth century, everybody, including myself, upon being shifted by revolution and expatriation from the Julian calendar to the Gregorian, used to add thirteen, instead of twelve days to the 10th of April. The error is serious. What is to be done? I find “April 23″ under “birth date” in my most recent passport, which is also the birth date of Shakespeare, my nephew Vladimir Sikorski, Shirley Temple and Hazel Brown (who, moreover, shares my passport). This, then, is the problem. Calculatory ineptitude prevents me from trying to solve it. [Speak, Memory, 1951]

Every time must be associated with a place, in the form of a time zone.

To handle time correctly, keep in mind one basic rule: every time must be associated with a place, in the form of a time zone.

(This advice may have a familiar ring to readers of Joel on Software’s The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) and its admonition that “It does not make sense to have a string without knowing what encoding it uses.

In addition, you need a historical database of the time-related legislation in each of these places. These basic requirements pose problems for many popular development platforms: for example, neither Flash/Flex nor Javascript have a proper notion of a time zone. Instead, they treat all times as in either the local time zone or UTC - if you want to schedule a meeting elsewhere in the world, or if your server happens to be in a different time zone than your browser, you’re in trouble.

Fortunately, many platforms (e.g. Linux, Windows, Java) do include a time zone database and a way to associate time zones with a time. The APIs are not always particularly clean (.NET has a TimeZone class that you shouldn’t use; the Java Date class has approximately five times as many deprecated as non-deprecated methods), but they work. Given a number of milliseconds since the epoch, a time zone, and a format, you can show the right text to the person using your software. You can even let them input a date and time (but be careful - which 2:30 am on November 4th do they mean?).

If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight.

Things get trickier when you start dealing with concepts that are less precise than a specific instant in time. If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight: it’ll only be six on the day that Daylight Savings Time starts and eight when it ends. If someone wants to see all sales that happened on Christmas Day, 2007, you have to know if they mean December 25th in their time zone, or the one in which the sale occurred (and furthermore, you need to store your data in a way that makes the appropriate query efficient). You can’t make any assumptions about the future either. Laws change; Daylight Savings Time is enacted, repealed, shifted; your time zone database needs to be kept up-to-date or your software will end up like the alarm system in our office - its time is off by an hour for a few weeks every Spring and Fall.

All of which is to say that handling time is harder than it seems. But if you keep the basic principle in mind, and code carefully, you should be able to figure out what time it is.

Tags: .NET, APIs, Daylight Savings Time, Flash, Flex, Javascript, Joel on Software, Linux, Vladimir Nabokov, Windows

This entry was posted on Wednesday, April 2nd, 2008 at 4:41 pm and is filed under Synthesis. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.