JavaScript, time zones, and daylight savings time

 

Welcome to this week's episode of Yet Another Time Zone Question :

I've done a fair bit of reading on SO, tried to manipulate moment.js and date.js into helping me, and generally been plagued by a feeling of frustration since I started trying to solve this, so if someone could help or point me at the duplicate question on SO that I just haven't been able to find, that'd be awesome.

I have a page. This page displays a series of times, eg: 7:28, 7:38, 7:48. I know whether these are AM/PM. These times are always America/New York (they do not change when daylight savings time changes, as the event they correspond to always happens at that time regardless of DST). Let's call them a schedule. I want to highlight the time that is coming up next.

  • This is trivial for people living in America/New York.
  • This is not too terrible for people living in America/Los Angeles (assuming my logic works).
  • I can take the current time of the computer in America/Los Angeles, convert it to UTC, then determine if America/Los Angeles is currently observing DST or not and determine whether America/New York should be -0400 or -0500, apply that to the UTC, and make my comparison. This hurts a little because you're still always dealing with a Date based in America/Los Angeles and not actually changing the time zone of the Date object, but I have a reliable means of rolling back (or forward) the hours from the UTC time.

    • What happens, however, when I try to determine if daylight savings time is being observed from a computer in a region that does not observe daylight savings time at all?

    JavaScript will only create Date objects for the current time zone, to my knowledge, and then doing any determination of DST is based on that Date object.

    Should I just not care? The times are primarily relevant only to people living in America/New York anyway. I'm just trying to build an application that makes sense when viewed from another time zone such that when it's 3AM in country_without_DST and it's 2PM in America/New York, the 'schedule' highlights that the 2:05PM thing is about to happen and not the 3:05AM thing.

    All comparisons with time should be done with getTime() of your instance. This returns the number of milliseconds since the UTC epoch. DST won't matter. You send the getTime() value to your server. Your clientside scripts will then convert this value back into a JavaScript Date object like so: 

    mydate = new Date(longmillisFromAnotherTZ);

    Then use any method on mydate to display the date how you'd like. Does this make sense? I'm failing to see how there's an issue. I'd be happy to clear anything up though.

    Edit:

    Just to be 100% clear...

    If two different clients need to display their actions to each other in different time zones, I'm suggesting that you use only the value from (new Date()).getTime() and then save that to the server. The server then sends this value to each respective client. The client is then responsible for displaying it in its own appropriate locale.

    Also, if you want a library that is good for getting timezones and offsets, getTimezoneOffset() is known to be flakey, you should check out this library: http://www.pageloom.com/automatic-timezone-detection-with-javascript

    Ah, I think I finally see what you're saying. You want to say something like, "The current time in NYC is _ " based on the time that's on the user's computer, and while there's support (at least in the docs) for setTimezone("EDT") there doesn't appear to be support for setTimezone("America/New York") . You'll either have to hard code the dates for when to switch between EDT and EST (based on current time GMT, which you can get from the user's computer), or use a 3rd party API (or do this on the server side).

    链接地址: http://www.djcxy.com/p/29374.html

    上一篇: moment.js，时区和夏令时

    下一篇: JavaScript，时区和夏令时