Andrew Paprocki (2013-02-20T14:24:07.000Z)
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/b393e313/attachment.html>
github at esdiscuss.org (2013-07-12T02:26:28.072Z)
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/b393e313/attachment.html>