Daylight Saving and MovableType

Posted: March 28th, 2003 | 7 Comments »

This weekend, Europe switches to Daylight Saving Time, and all the clocks move forward an hour. Phil wondered if one should alter the timezone setting in one’s MovableType blog accordingly.

The short answer is that you probably don’t have to. That is, as long as your MT server is in the same country as you. And you’re not in Australia. Or Indiana.

Beyond that, unfortunately, things get a little complicated. Let’s briefly skim over this particularly-hideous corner of the arcana that is computational chronometry…

Doing anything with dates and times in programming has pitfalls. Most programmers either don’t think about them or think for a few minutes before sticking their fingers in their ears and shouting LALALALA CAN’T HEAR YOU. The most obvious case of this is/was the Y2K bug. Then there’s the slightly-lesser-known Y2038 bug. Both of these are obvious, stupid problems – very easy to explain and thoroughly spankable. If you want an example of code that’s built to last, Mark Crispin‘s extensive and fascinating research into how calendars work for the UW IMAP server deserves some kind of award, if only for the paragraph

There is code in c-client to support the modified Gregorian
calendar, although it is currently disabled. Sometime in the next
2000 years, someone will need to enable this code so that c-client is
Y4K compiliant. Then, 18,000 years from now, someone will have to
tear into c-client’s code to fix the Y20K bug.

… by which time, hopefully, UW IMAP will have finished opening my INBOX.

Thing is, that isn’t even the particularly scary stuff. If you want hardcore terror, try coding anything involving timezones and Daylight Saving Time without decent libraries. You will know pain.

I didn’t fully realise the extent of this until today, when I was trying to answer Phil’s question about MovableType. My first reaction was that surely MT should just obtain the current time and date from Perl’s localtime(), which will usually give you the right current time for the server, taking DST into account. The problem is that since MT is a server application, an MT user might not be in the same timezone as the server. This is quite common: She, for example, lives in Jerusalem but her Unbroken Glass is hosted by us, a.k.a. J-Colo, on our server in London.

MT acknowledges this by allowing timezone configuration on a per-blog basis. Here’s the drop-down in question:

Time zone not selected
UTC+12 (International Date Line East)
UTC+11
UTC+10 (East Australian Time)
UTC+9.5 (Central Australian Time)
UTC+9 (Japan Time)
UTC+8 (China Coast Time)
UTC+7 (West Australian Time)
UTC+6.5 (North Sumatra)
UTC+6 (Russian Federation Zone 5)
UTC+5.5 (Indian)
UTC+5 (Russian Federation Zone 4)
UTC+4 (Russian Federation Zone 3)
UTC+3.5 (Iran)
UTC+3 (Baghdad Time/Moscow Time)
UTC+2 (Eastern Europe Time)
UTC+1 (Central European Time)
UTC+0 (Universal Time Coordinated)
UTC-1 (West Africa Time)
UTC-2 (Azores Time)
UTC-3 (Atlantic Time)
UTC-3.5 (Newfoundland)
UTC-4 (Atlantic Time)
UTC-5 (Eastern Time)
UTC-6 (Central Time)
UTC-7 (Mountain Time)
UTC-8 (Pacific Time)
UTC-9 (Alaskan Time)
UTC-10 (Aleutians-Hawaii Time)
UTC-11 (Nome Time)

One of the neat things there is that it doesn’t make the usual mistaken assumption that timezones are uniform longitudinal slices that are always a whole number of hours apart. Yes, you really do get half-hour differences.

The trouble with basing timezone-handling entirely on UTC zones is that it doesn’t take Daylight Saving Time into consideration. Despite UTC+1 being described as Central European Time, during the summer Central Europe is on UTC+2. After a quick shufti through MT’s excellent module documentation, I discovered that it has a stab at handling DST:

offset_time_list($unix_ts, $blog [, $direction ])

Given $unix_ts, a timestamp in Unix epoch format (seconds
since 1970), applies the timezone offset specified in the
blog $blog (either an MT::Blog object or a numeric blog
ID). If daylight saving time is in effect in the local
time zone (determined using the return value from local-
time()), the offset is automatically adjusted.

Returns the return value of gmtime() given the adjusted
Unix timestamp.

In other words, MT checks whether it’s DST on the server and makes that adjustment to the user’s timezone. With all due respect to Ben Trott (and much respect is due) this is wrong for these reasons:

1. Firstly, there’s a usability issue: Suppose a reasonably savvy user is creating a blog during DST. Because the user isn’t told that MT does DST offsetting, they may make the mental calculation and choose an offset timezone in the dropdown, intending to set it back manually when DST ends.
2. If you’re in the other hemisphere to the server, then MT will spend most of the year giving you the wrong time, since the server will be on DST when you’re not and vice-versa. (I can’t tell from the source whether the optional $direction would fix this, but given that it doesn’t seem to be used anywhere in MT, it’s irrelevant)
3. Even if you’re in the same hemisphere, your server’s location may still start DST on a different date to you, providing a couple of weeks out of sync.

It’s at this point that the brainhammers move in, because if you’re going to do a decent job of calculating DST, you need to know where you are, and I mean really know where you are. While all of Europe starts and ends DST at the same time, other countries vary wildly from each other, and some aren’t even able to keep it consistent internally. Australia is a prime example: each state sets its own DST dates. Israel decides its DST start and end dates every year to ensure they don’t clash with the High Holy Days. However, that doesn’t include the Occupied Territories because the Palestinian Authority, clearly sick of all the mucking about, moved to solid dates at the first chance it had.

(Also of note is that, this year, Europe moves to DST two days before Iraq does, which is five days before the US does, guaranteeing a week of fascinating confusion for international cooperation and media efforts)

If you’re interested in DST and its history, easily the best site I’ve found is this one at WebExhibits, which not only has plenty on the history and reasoning behind DST but also a useful reference page of what different countries do, when and why. (Plus an explanation of Indiana’s weirdnesses and the fact that after the US extended DST by three weeks they saved 300,000 barrels of oil each year).

But back to the central problem, which is: how the hell do you code for this mess? It turns out that help is at hand; what’s more, it’s at hand on every modern *NIX OS in the form of the tz database (also known as Olson or zoneinfo). It features a large set of timezones divided according to continent and subarea, such as “Europe/London”. Originally created by Arthur Olson in 1994, this is now maintained as a group effort, and the GNU C library (glibc) provides date and time functions that use it, such as the aforementioned localtime().

Date and time manipulation in Perl has, until now, been a confusing (if colourful) mess – see this perl.com summary of the many modules available. The author of that piece, Dave Rolsky, is working on a new set of modules, intended to become authoritative. He’s already released initial versions of DateTime::TimeZone which features the entire tz database converted to Perl modules and weighs in at a scary 400k gzipped. (Hey, that’s big for a Perl module)

DateTime::TimeZone is probably already good enough to be able to be dropped into the next version of MT, which would mostly solve the problem. I say “mostly” because it probably won’t be able to handle the Israeli government’s indecisiveness, and so poor She will still have to deal with wrong timings on her entries. (Not that one hour’s difference is that big a deal, but still.) Personally, I’d like to see DT::TZ as the default, but with the option to turn it off and just do like Phil suggested: change the clock yourself.

---