Jon-- 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. Good luck… --Rich Gillam Lab126 On Feb 20, 2013, at 11:38 AM, Jonathan Adams wrote: > Rich, > > 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" <[email protected]> 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 [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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
