Martin Atkins (mart) wrote in lj_dev,
Martin Atkins
mart
lj_dev

Rambling about Timezones

I read over Brad's ancient document on timezones (August 2000!) to remind myself of the issues, so here's some rambling on the subject of timezone support in LJ.

The current state of affairs is that the flat protocol (and XML-RPC too, I hope) supports a “tz” field for postevent which can either be set to “guess” to have the server guess a timezone or a four-digit time offset, such as +0100, -0700 or +0000. (That's HHMM, by the way). At the moment not a lot is done with this and no clients actually send it, but at least the thought is there. As far as I know, logtime and comment post times are now being stored as GMT (Brad?) which is also a good start.

With this in mind, I think we need to do some or all of the following:

  • Have a GMT offset stored for each entry, and keep entrytime in GMT. On post, use the timezone field to calculate a GMT version of the given event time and store that, along with the current time in GMT.

  • If a value for timezone (other than “guess”) is sent with postevent, allow all of the date and time fields to be omitted, saying to the server (which is pretty accurate since it's set to a good clock by ntp) “use the current time”. It's an error to include some fields but not others, though; all or nothing. This becomes the recommended way to submit any entry that does not have the date explicitly set by the user, thus removing the problem of client-side clocks being wrong.

  • Clients should use some locally-defined way to detect a sensible timezone. Windows “knows” what timezone it is in, as does every other major OS I'd imagine. I know that both Windows and my Linux boxes manage to track daylight savings time properly too. This setting should be the default, but users should be able to override it if they know better. (how they override it is an implementation issue) (Can the “web client” determine the local timezone from JavaScript?)

  • Allow users to select the following two settings for their account:

    • A “display” timezone used for display purposes whenever something needs to be viewed in the user's local time. This could possibly be overridable with a cookie for non-users or users who want to change their setting temporarily.
    • A “default” zone used if a client sends a postevent with no timezone setting; we simply assume the given time is in the default timezone.

    These are the only two timezone settings here which are stored, rather than as absolute GMT offsets, as identifiers which map onto some settings describing daylight savings time etc. Data on the special rules for different regions is readily available and even comes with most linux distros. I'm sure there's a perl module around which can parse and use this data. The purpose of storing these this way is to allow for automagically using the correct offset at different times of year without the user explicitly changing it.

  • Sort all journal views by the GMT value stored in eventtime. Friends view will no longer sorted by logtime. (Yay!)

  • For S1, just supply the time to the styles in the poster's timezone, mimicking current behavior. The friends page will still do the wonky behavior with start/end day, but at least it won't get any worse.

  • S2 improvements abound:

    </p>
    • Extend Date to contain a new member containing the timezone offset as a string like the timezone field in the protocol, and give a way to resolve that to a human-friendly (and localized) display string such as “PDT” or “BST”.

    • Supply a new member in the S2 EntryLite class called localtime. This will contain the time in the timezone set as default by the journal owner. This may sound a bit weird since we're ignoring the viewer's selected display timezone, but current convention is that in S2 the journal owner wins: we don't use the viewer's browselang for language, for example.

    • The time in EntryLite goes on being in the poster's timezone: the values are set as for S1's time. We have the new field containing the timezone, however, so this is no longer ambiguous.

    • System layouts can be modified to display both the poster's time and the local time, but only if the two fields have different timezones. No sense in displaying redundant data; remember that localtime is calculated from the same GMT time as eventtime, so if the timezones are the same they will be identical.

    • The “new day” stuff should group based on the local time field, not on the poster's time. This is of most importance on the friends view, but is also important on the recent view where entries could be posted by users in different timezones (community/shared journals) or by a single user who goes to a different timezone temporarily.

    Existing non-system layouts will go on doing what they do now: displaying the poster's time. This means the layout owner can go back and add the new time at their leisure. (In other words, it's backwards compatible)

  • Pre-timezone entries will assume the poster's default timezone. The user can manually set the timezone on any entries for which this is not correct. (I assume most people stay in one timezone most of the time)

  • The protocol will block posting of entries without a timezone specification until a default timezone has been selected. This is probably the most controversial thing here, but it will encourage — neigh, force — users to choose their timezone, avoiding incorrect data accumulating while they don't realise they need to. The web-based interface could potentially be clever and just present the “choose default timezone” form to the user the first time they try to post without one set, being very careful to emphasis that it's a default timezone, not just for this entry.

  • New users will be required to choose their timezone on signup. This could be part of a new hand-holdy multi-step signup process which allows users to pick their default language (later), default/display timezones and an initial S2 layout from a subset of the available system layouts. (The last of these is inspired by Blogger's signup process, and I recieved good feedback on this idea when I proposed it a few years back.)

Well, that was long. Still, Brad said he was thinking about moving up to dataversion 3 with some major changes, so timezones might as well be one of these major changes. If anyone is brave enough to read this big, rambly list it'd be cool to discuss this.

Quick note: I don't have time to work on this stuff right now, and it's probably not going to be done for a while yet. :)

Tags: timezones
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 21 comments