On Jul 17, 2013, at 20:29 , Brendan Eich <[email protected]> wrote:
> Norbert Lindenberg wrote: >> On Jul 17, 2013, at 13:58 , Brendan Eich<[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
