4

Possible Duplicate:
Javascript/PHP and timezones

It is possible to get the Olson timezone id from javascript on the client's machine e.g. (America/New York). I know that PHP can do this via the timezone object, something like this. $timezone->getLocation(); Does similar functionality exist for JS?

I know that you can grab the timezone offset of the client as followed: var curdate = new Date(); var offset = curdate.getTimeZoneOffset();

But I need more granular information provided by the Olson Id. Thank you for your help.

Community
  • 1
  • 1
usumoio
  • 3,500
  • 6
  • 31
  • 57

1 Answers1

3

You can't directly access timezone in JavaScript. You can, however, measure offsets reported at several different specific dates to deduce what exactly time zone is in use by comparing regular and daylight savings times to database of zones. There's a jsTimezoneDetect library that can do most of this work for you.

Oleg V. Volkov
  • 21,719
  • 4
  • 44
  • 68
  • This mechanism allows you to get a **currently equivalent** time zone, but it doesn't actually get the real time zone. – Sam Jul 23 '13 at 23:12
  • This is true, but considering you can resync on every run of JS and always find fresh equivalent zone, it should be enough for pretty much all purposes. – Oleg V. Volkov Jul 24 '13 at 11:08
  • I suppose it depends on what you want to use the time zone for. I'm thinking of web application scenarios where a user enters a time, and some JS code also provides the time zone for the time so that the server can unambiguously interpret it. In these cases, I don't think this mechanism is sufficient, especially for future times, in which case DST rules of the real time zone could be changed in the future. – Sam Jul 25 '13 at 01:45
  • @Sam, if you want your time always displayed correctly, there's exactly one way: store everything in UTC and use method described in answer to deduce current zone to display time for user in UI in his local time. – Oleg V. Volkov Jul 28 '13 at 15:27
  • Imagine a user enters a future time for an appointment at 8AM, local time. The application converts it to UTC using the equivalent timezone provided by the library you're recommending. The application stores this UTC value. Imagine that the DST rule for the time zone changes, affecting the UTC time. (This happens in real life.) When the application then presents the time to the user, converting to the user's equivalent time zone, it will be wrong. – Sam Jul 29 '13 at 00:06
  • (Sorry if my second-last comment sounded rude; I've removed it in case it did.) – Sam Jul 29 '13 at 00:14
  • 1
    @Sam, most changes to timezones are known and updated in respective environments/OSes reasonably in advance, and thus for most practical purposes this will be handled correctly and transparently. If user happens to set appointment for a few years forward in future, there's always "edit" button. – Oleg V. Volkov Jul 29 '13 at 09:19
  • Therefore your "exactly one way" that causes times to be "always displayed correctly" doesn't **always** display times correctly. I agree that your suggestions should work *in general*, but I think you're over-generalising, which is dangerous to people who take your word for it. – Sam Jul 30 '13 at 04:01