gillam at lab126.com
Wed Feb 20 11:47:55 PST 2013
The current version of the spec is here: http://www.ecma-international.org/publications/standards/Ecma-402.htm
What discussion takes place on this standard mostly takes place on this list, and TC39 is ultimately responsible for the standard, although there's an ad-hoc group that does most of the work. I don't remember if TC39's "strawman" pages are open, but there's discussion of the next version of ECMA 402 going on there.
On Feb 20, 2013, at 11:38 AM, Jonathan Adams wrote:
> This sounds great. Yehuda Katz had hinted at this but the namespace is so polluted I was struggling to find anything official. Where can I go to follow this development?
> Jon Adams
> +1.530.908.1977 • skype: pointlessjon
> On Feb 20, 2013, at 11:32, "Gillam, Richard" <gillam at lab126.com> wrote:
>> Wait a minute. I may be misunderstanding here, but all of this discussion sounds misguided to me.
>> A Date is intended to represent a specific instance in time, irrespective of time zone. You don't want to go adding time-zone-related fields to the Date object. Time zone becomes important when you're doing calculations on a time (converting it into year/month/day/hour/minute/second, etc.) or when you're converting it to a textual representation for display to the user. This is what the DateTimeFormat class in the ECMAScript internationalization spec is for, and it handles time zone. There's still a lot of work to do there, of course, but let's not break the whole model.
>> --Rich Gillam
>> Internationalization geek
>> On Feb 19, 2013, at 9:52 PM, Jonathan Adams wrote:
>>> I understand that an implementation of ECMAScript is expected to determine the local time zone adjustment .
>>> 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  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  and wrestle with daylight savings time adjustments .
>>> 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.
>>>  http://people.mozilla.org/~jorendorff/es6-draft.html#sec-126.96.36.199
>>>  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013322.html
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
More information about the es-discuss