On Jul 17, 2013, at 16:59 , Jonas Sicking <jonas at sicking.cc> wrote:

> On Wed, Jul 17, 2013 at 7:55 PM, Brandon Benvie <bbenvie at mozilla.com> wrote:
>> On 7/17/2013 4:54 PM, Norbert Lindenberg wrote:
>>> 
>>> On Jul 17, 2013, at 16:51 , Brandon Benvie <bbenvie at mozilla.com> 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

On Jul 17, 2013, at 16:59 , Jonas Sicking <jonas at sicking.cc> wrote:
> 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.