On Jul 17, 2013, at 16:59 , Jonas Sicking <[email protected]> wrote: > On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie <[email protected]> wrote: >> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote: >>> >>> On Jul 17, 2013, at 16:51 , Brandon Benvie <[email protected]> wrote: >>> >>>> On 7/17/2013 4:42 PM, Brandon Benvie wrote: >>>>> >>>>> On 7/17/2013 4:36 PM, Jonas Sicking wrote: >>>>>> >>>>>> Is this simply a SpiderMonkey bug? Do we expect JS code to be able to >>>>>> handle Date objects representing timezones other than the user's >>>>>> current timezone? >>>>> >>>>> What happens if the timezone changes between the creation of two Date >>>>> objects, such as for daylight savings or the user changes their system >>>>> timezone? >>>> >>>> Having just tested this, it is possible in SM to get two Dates that >>>> report different values from getTimezoneOffset. >>> >>> How? >>> >>> Norbert >>> >> >> Create a Date object, change the system timezone, create a second Date >> object. They reflect the timezone at time of Date object creation, not a >> static one. > > That doesn't reflect what I'm seeing. I see the timezone of all Date > objects changing whenever the timezone is update. Existing instances > are also changed.
Seeing getTimezoneOffset change for *all* Date objects is what I expect because none of them actually *have* a time zone - getTimezoneOffset uses the one local time zone that the JavaScript engine maintains somewhere. Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
