0

In Javascript it's fairly straightforward to render and manipulate dates in the current user's local time zone using the methods of the Date object. For example, toLocaleString() for output and the 7-argument form of the Date constructor for input. So up until now I haven't even bothered setting a time zone as a user preference. Internally everything is stored, computed and sent back and forth to the client using UTC, and we do the translation client-side for both input and output.

For example, suppose a user has their local machine's time zone set to US Eastern. When looking at my web page, an event that occurred at Unix timestamp 1359416775000 would render as, say "Mon Jan 28 18:46:15 2013" with code no more complex than 

new Date(1359416775000).toLocaleString();

But suppose I need to send that user an email about this event. What time zone should I use to render the timestamp in this email? The obvious answer is to let the user pick their time zone. Now suppose I do this and this user picks US/Eastern. Great. Now suppose the next time the user logs into my website their local machine is on US Central time. That same piece of Javascript code would now cause the timestamp to render as "Mon Jan 28 17:46:15 2013".

Is this really the right behavior? The user has picked a time zone in my application, but it only applies to email?

This seems like a common enough problem that I feel like there ought to be a common best practice, I'm just wondering what that is.

Dan
  • 10,990
  • 7
  • 51
  • 80

2 Answers2

2

You should, by default always display times in the users local time zone. At any point of you display the time using another time zone, this should be made clear by also printing the timezone.

As such, if the users time zone is US/Eastern, you would display a time in hos time zone, in your example "Mon Jan 28 18:46:15 2013", while if you show him an event that actually happens in US/Central, you should show "Mon Jan 28 17:46:15 2013 US/Central".

Now if the user moves to a computer whose time zone is US/Central, then yes, as default you should now show him the time in US/Central. So you would in both cases display the date as "Mon Jan 28 18:46:15 2013", no time zone necessary. They will have the computers current time in the corner of the screen, so it won't cause much confusion.

If you let the user pick his timezone, which is common in sites where the time display isn't decided by the client time zone setting, then you should by default show the times in that time zone all the time, no matter what time zone the computer is in. Remember that it is up to the user to make sure his computer is in the right time zone. Most people who travel with their laptops won't change the time zone when they move.

It is theoretically possible for you to warn the user that he has selected another time zone than the one he seems to be located in, by getting a geolocation from the IP. But unless you are writing a calendar application I would think that annoys people more than it helps them.

Lennart Regebro
  • 167,292
  • 41
  • 224
  • 251
1

Unfortunately you cannot set the user's timezone which is used by the non-UTC date methods.

You can only work around that by adding/substracting your custom timezone offset when outputting/reading a date, like in this example.

Community
  • 1
  • 1
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • Right, that's what I'm trying to avoid. Is it really the convention on websites that allow the user to select a timezone to use only that timezone and ignore their local machine settings when rendering dates? – Dan Jan 28 '13 at 23:53
  • I don't know about "convention", but it's the only way to be done properly. However, it does not mean to *ignore* the user's local settings, they still can be used as the default timezone selection. – Bergi Jan 29 '13 at 00:26