Frozen Date objects?

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Thu Jul 18 09:41:51 PDT 2013


On Jul 17, 2013, at 20:29 , Brendan Eich <brendan at mozilla.com> wrote:

> Norbert Lindenberg wrote:
>> On Jul 17, 2013, at 13:58 , Brendan Eich<brendan at mozilla.com>  wrote:
>> 
>>> No, *time* is stored as milliseconds after the epoch in a number (IEEE double).
>>> 
>>> A Date object includes position on planet and timezone politics (see getTimezoneOffset).
>> 
>> No, it doesn't. Any time zone information used by getTimeZoneOffset and other non-UTC Date API is based on time zone information in the environment: the "local time zone" is typically what the user has told the OS to use. A Date object itself only wraps the time value.
> 
> No. This is not well-specified by ECMA-262, implementations do crack time to date fields in Date instances, and one's timezone can change in a running system (say a Firefox OS phone one takes on a plane).

Implementations are free to cache all kinds of things to improve performance, but they still have to produce the specified behavior. The behavior of Date non-UTC methods is defined in terms of a single time value and conversion functions that rely on local time zone adjustment and local daylight saving time adjustment. The spec text varies a bit between ES5 and ES6, but my interpretation of both would be that when the local time zone changes, the results of LocalTZA, DaylightSavingTA, and LocalTime all change, so caches based on them have to be invalidated.

If some or all implementations have interpreted that differently, then the spec needs to be clarified one way or another.

Norbert


More information about the es-discuss mailing list