Override LocalTZA

[Andrew Paprocki]

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 <andrew at ishiboo.com> 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 <pointlessjon at me.com>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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130220/0198af84/attachment.html>