I suppose I should add that the DateTz approach works only if you embed the IANA "Olson" tzdb with the engine rather than requiring the platform to provide it. Working with different timezones is problematic when going through libc (setting/resetting environment variables), and Windows does not use IANA strings. The DateTz trick only works because it is doing the IANA tzdb calculations itself and accessing its internal two ES Date objects (real UTC timestamp and one with the "shifted" UTC timestamp) via their UTC methods so that the engine itself does not attempt to do any translations.
I would love to see something like DateTz be provided by the spec, but it means a shift to explicitly require native tzdb support by the engine rather than simply relying on the platform to handle conversions for whatever the current user's platform tz setting is. This then means implementations would have to stay up-to-date with tzdb releases (ala Java) to ensure they get proper DST updates. Maybe with the faster release cycles now used this is within the realm of possibility.. -Andrew On Wed, Feb 20, 2013 at 9:24 AM, Andrew Paprocki <[email protected]> wrote: > The approach I've taken is to implement a native DateTz type which > internally stores the UTC Date as well as the Date in the offset specified > by either the user or an IANA timezone string. The non-UTC ES Date API then > returns the local datetime in the specified timezone. The API is kept to a > minimum to avoid adding much on top of the ES Date: > > DateTz(msec, offset) > DateTz.inTz(msec, tzstring) > > e.g. > var a = new DateTz(Date.now(), -300); > var b = DateTz.inTz(Date.now(), "Asia/Tokyo"); > > The returned objects simply proxy the public API of ES Date to the > internal Date objects, so the above are the only real additions to the API > surface. > > -Andrew > > > On Wed, Feb 20, 2013 at 12:52 AM, Jonathan Adams <[email protected]>wrote: > >> I understand that an implementation of ECMAScript is expected to >> determine the local time zone adjustment [1]. >> >> This is really convenient -- most of the time. However, it would be great >> to override this for a given Date object. It doesn't appear that we can at >> the moment [2] or in ES6. >> >> If we could override this context, we can then take advantage of some of >> the other native methods such as Date.toString(), Date.getDate() etc. using >> our preferred, altered LocalTZA rather than users having to build horrible >> user-land functions [3] and wrestle with daylight savings time adjustments >> [4]. >> >> My particular use-case involves taking dates generated in CST, stored as >> UTC (this is good) but then I want to offer a list of dates relative to >> CST, but this is processed in a context with LocalTZA for PST. I can get >> away with faking it by calculating the difference in timezones and altering >> the timestamp used to generate a new Date object but, this is going to >> technically be off at some points in time (DST adjustment for example) and >> feels wrong/hacky. >> >> -Jon- >> >> [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.9.1.7 >> [2] >> http://stackoverflow.com/questions/9369972/can-i-set-the-local-timezone-in-my-browser-via-javascript >> [3] >> http://www.techrepublic.com/article/convert-the-local-time-to-another-time-zone-with-this-javascript/6016329 >> [4] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013322.html >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
