Time zones: do we really need them?

While looking at StatusNet’s preferences dialog, I noticed we have a fairly generic but unfriendly timezone selector, done as a drop-down box with a raw list of zone names — this makes you find and select something like “America/Los_Angeles” or “Asia/Tokyo”:

Not only is the list very long and confusingly sorted, but the names are all either English or acronyms, making it hard to internationalize.

It occurs to me that we very rarely actually output formatted dates in the web interface anyway… most of the time we output relative times like “a few seconds ago” or “3 months ago”.

In fact, about the only place I can see that we’re outputting a fully formatted date is on an individual notice like this:

“Brion Vibber (brionv) ‘s status on Friday, 27-Nov-09 19:19:11 UTC”
“Brion Vibber (brionv) ‘s status on Friday, 27-Nov-09 11:19:11 PST”
etc

though we also have tooltips on the approximation eg “about a month ago”: “2009-11-27T11:19:11-08:00”

My own inclination would be to drop the timezone preferences entirely; in the rare cases where we output a formatted local date we can let client-side JavaScript do the actual date formatting with the client system’s actual time zone and language settings, with a UTC/GMT fallback for clients with JS disabled.

This drops an unnecessary and hard-to-select option field from preferences and site administration panels, and avoids inconsistencies when you travel or move and forget to update the timezone.

Any objections or suggestions for further refinement?

4 thoughts on “Time zones: do we really need them?”

  1. I think the best way to do it is have a server-side preference, but keep it updated via JS. On registration, have JavaScript autodetect the right setting and submit it. Thereafter, maybe even on every page load, you could check the user’s preferred timezone and compare via JS against the current system timezone, and update the preference automatically (via AJAX or whatnot) if there’s a mismatch. Should be a simple variable compare in the common case, no noticeable client-side overhead, and requires no more JS than necessary.

    For people whose system time is wrong, or who don’t use JS, you could have a preference somewhere out of the way, with the default being “Autodetect using JavaScript”.

  2. While this might not work for everyone, I’m fairly certain that you could correlate geo-IP data with time-zone data of the notices.
    (The slight extra information this would result in in addition to the UTC time is that you could see if someone was “denting”, for example, in the middle of the night…)

  3. You could still have the selection box, but an onLoad hook or somesuch that, if JS is enabled, changes it from ‘please select’ to ‘auto-detect’ and then you satisfy every browser (and those who might want to manually set a timezone) and make it easy for others.

Comments are closed.