[typo] Timezones

mathew meta at pobox.com
Sat Apr 22 12:06:27 EDT 2006

Syed Uzair Aqeel wrote:
> Y'know, it'd be nice if I could specify a time offset in the admin interface
> so that my blog lived in the same timezone as me. I host with DreamHost,
> which is currently in PDT, whereas I'm in the UK. I know blog clients like
> Ecto (http://ecto.kung-foo.tv) allow one to set an offset, but I normally
> use either the Admin interface or the Performancing extension
> (http://performancing.com/) to post, and neither of those have a similar
> option. (To be fair, if you're not doing a 'Quick Post' one can adjust the
> time of publishing manually in the Admin interface, but it's tedious doing
> this for each blog entry).
> I suspect this would be a fairly simple fix, so I'll try throwing my creaky
> Ruby skillz at it.

It's a lot less simple than it looks, because the underlying database 
doesn't have any time zone information, at least if you use the standard 
schemas provided. I've written calendar software, so I'm acutely aware 
of how many pitfalls there are.

Suppose you start with a simple admin preference for time zone. So, now 
you know the user's time zone is -0600. Now you're faced with the 
problem of what to actually store in the database.

Initially, you leave the code as is. The time and date for creation and 
modification are added by Rails, in the server's time zone. You simply 
adjust it to/from the user's time zone for web pages and forms, by using 
the preference time zone, and the server's time zone.

Then you think: what if your web host has a problem or raises its 
prices, and you move to a different host? Or what happens when you move 
to a different time zone? Suddenly all the dates and times for stuff 
posted before you move will apparently change, relative to things posted 
after you move. You'll have to run through the entire database, changing 
the date and time stamps from the old server's time zone to the new 
server's time zone. Or if you move, you'll need to compute the 
difference between your old time zone and the server's time zone, 
compare that to the difference between your new time zone and the 
server's time zone, and use the difference between *those* values to 
process all your existing data.

OK, that's not good. So, what if you use the preference to adjust the 
time on the form, but then store the adjusted time, in the user's time 
zone at the time of the posting? Time on form looks right, time on web 
page looks right, even if you change hosts or move. End of problem yes?

Well, sorta. When you move the time stamps remain the same, but all 
you've really done is hide the problem--now there's a discontinuity in 
what they *mean*. The web site will be showing dates and times in time 
zone A before your move date, and in time zone B after your move date. 
Depending on how often you move, this could get very confusing.

So you think a bit, and decide to store the date and time in a single 
time zone for all eternity. The obvious choice is UTC. You adjust times 
to and from UTC, based on the preference set in the admin interface. 
Move to a new time zone? Data's still all valid, just change the 
preference and every page of the web site snaps to the new time zone. Great.

Then autumn arrives, and you drop out of Daylight Saving Time. Oops. 
Your post at 6pm in July now looks like you posted it at 5pm. So you 
decide the right thing to do is to adjust automatically for DST. How 
hard can that be, eh?

The answer is, pretty damn hard. Take my case, for example. My data set 
goes back to 1987. Before 1997 I was in the UK, and during that time the 
UK set its DST changeover dates by Act of Parliament, so they were 
different from year to year. Then I moved to the US, for a different set 
of DST changeover dates. Then the US passed a law changing its DST as of 
next year. Luckily I didn't live in parts of Indiana, or there would 
have been times of my life when I didn't observe DST at all. (As it was, 
when I imported my data I passed each date/time stamp through an 
algorithm that worked out missing time zones based on my personal history.)

So, to adjust UTC times in the database for DST, you need a general 
mechanism for specifying start date and end date of DST for all years 
for which there is data, as the dates change from year to year.

If you've read this far, you may now understand why I modified the 
schema I use to actually record the time zone for each entry. This at 
least means my existing data remains intact, and new entries get 
timestamped with enough information to let me locate them in time in the 
future. All I need now is a way to use that information when generating 
the pages...

The other option, of course, is to store *and display* everything in 
UTC. I gave that some serious consideration too, but didn't run with it 
as it would have required that I make code changes to typo--whereas 
changing the schema "just works" because of the magic of Rails.

So before you start hacking code, I'd suggest that you think about the 
fact that (as I've explained above) UTC for storage and display is the 
only really viable option, assuming (a) you want time stamps to have 
consistent meaning on all pages of the site, (b) you don't want to 
reprocess your entire data set periodically, (c) you don't want to store 
time zone offsets in the database, and (d) you don't want to deal with 
the complexities of manual DST adjustment.

When I'm elected supreme ruler of the world, I will do away with time 
zones and DST, and everyone will use UTC everywhere, on pain of 
imprisonment. Until then, good luck.


More information about the Typo-list mailing list