Dates and Timezones

Published 28 July 04 by Justin French, 1 comments

Specifically, I’m trying to decide on the best method of storing date and time information in Bandography.

In the case of news articles, blog entries, comments, forum posts, etc the answer appears to be storing the time stamp in GMT (Greenwich Mean Time). If we don’t, we loose information about what time it really was.

Then we have to display that time/date back to the user. We have plenty of options.

The method that Movable Type, Textpattern and many others seem to employ is to apply a site-wide time zone offset (e.g. +10hrs for Eastern Australian) to all dates & times.

The problem here is that if you change time zone (when moving house for example), the times of all your older posts won’t make sense anymore. The solution here seems to be recording the time zone offset with each and every post, but this certainly adds a of complexity to displaying dates and times.

The real (and more frequent) problem is that a site-wide offset forces the website owner to impose a time zone onto all of the website’s users. This is fine for something like a corporate intranet, but an absolute nightmare for the majority of websites which have a global user base.

To solve this dilemma, we could apply a user-preferred time zone offset (e.g. –8 for Pacific Time) for registered users/members of a site, and apply a default of either GMT or some other offset to visitors and non-registered users. Forums like PunBB appear to take this approach.

Great! But we now have a new problem. If we present dates & times with a user-preferred offset, any time-sensitive text in the article (e.g. “yesterday” or “this morning”) loses it’s meaning.

What a nightmare! I’m leaning towards a combined approach right now:

• Store all dates in GMT, and record the time zone offset of each post, using the current site-wide offset as the default
• possibly allow an “override” for when the writer is not in the default usual time zone (overkill?).
• allow a registered user the option of converting all time stamps into their preferred time zone.

But wait, there’s more!

Then there’s a completely different type of date and time – one which is provided in context of it’s location and local time zone, like a conference, meeting, show, performance or exhibition. In the case of Bandography, we’re talking about gigs and tour dates.

These need to be stored the local time zone of the physical event, and should not be offset by the server time, site-wide offset or user-preferred offset. July 5th 2004 @ 5:10pm in Sydney must always remain the same.

If all that hasn’t completely fried your brain, we haven’t even touched on Daylight Savings Time (DST) yet!