On 7/17/2013 4:55 PM, Jonas Sicking wrote:
> On Wed, Jul 17, 2013 at 4:42 PM, Brandon Benvie <bbenvie at mozilla.com> 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?
> I believe SpiderMonkey in Firefox Desktop until recently would grab
> the snapshot of the user's timezone on browser startup, and then never
> change it until the browser was shut down.
>
> Now it seems to update that snapshot now and then in some pattern that
> isn't obvious to me. When that happens the timezone offset for *all*
> Date instances all change.

Oh I see what happened. The time zone reported from getTimezoneOffset 
wasn't updated until a new Date object is created. So the original one 
would report the old timezone up until the first time you do `new Date` 
and then both the old one and the new one are changed.

On 7/17/2013 4:55 PM, Jonas Sicking wrote:
> I believe SpiderMonkey in Firefox Desktop until recently would grab
> the snapshot of the user's timezone on browser startup, and then never
> change it until the browser was shut down.
>
> Now it seems to update that snapshot now and then in some pattern that
> isn't obvious to me. When that happens the timezone offset for *all*
> Date instances all change.

Oh I see what happened. The time zone reported from getTimezoneOffset 
wasn't updated until a new Date object is created. So the original one 
would report the old timezone up until the first time you do `new Date` 
and then both the old one and the new one are changed.