[whatwg] Date Update?

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Sun Jan 19 16:30:50 PST 2014


On Jan 19, 2014, at 10:01 , Jasper St. Pierre <jstpierre at mecheye.net> wrote:

> On Sunday, January 19, 2014, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> 

> > What considerations are there for codifying the behavior for
> > Date.parse? Middle endian date format parsing works:
> > Date.parse("2/11/2013"); Should this be standardized here:
> > http://javascript.spec.whatwg.org/#date
> >
> > Any proposals for Date.prototype.format, ala strftime?

The ECMAScript Internationalization API provides date and time formatting, with an API that's more abstract and better suited to localization than strftime:
http://www.ecma-international.org/ecma-402/1.0/#sec-12
http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat

Parsing date and time input was considered for the second edition of that standard, but our impression was that most applications prefer date-and-time pickers, so we dropped parsing.

> > Any replacement proposals, like a Joda-Time, or others, that treat a
> > Date as a set of fields rather than an object represented by a number?
> > And maybe with add/subtract methods without having to resort to each
> > field? Zero-based month and one-based days are weird, but even weirder
> > with MakeDay adding the extra month onto the year field:
> >
> > var d = new Date(Date.now())
> > d.setMonth(12); // Next January, not December.
> 
> Date is a wrapper for a UNIX timestamp. It's not designed to be an accurate calendaring API. I feel like a calendering API should be related to Date and integrate with it, but a separate API altogether.
> 
> Computer representations of date and time are complicated enough, and should we want a standard calendering API, it should be done by not wrapping a UNIX timestamp.

Joda-Time doesn't treat Date as a set of fields; it uses a complete separate DateTime class. Treating Date as a set of fields, as the current Date API attempts, is inadequate because it doesn't allow for different calendars (Gregorian, Buddhist, Islamic, etc) and time zones. The getters and setters for fields in java.util.Date, for comparison, have all been deprecated.

That said, there hasn't been much interest in adding anything of the size of Joda-Time into ECMAScript. I proposed a while ago to make public the one-way mapping from Date values to date and time fields that's already specified in the Internationalization API spec, but even that hasn't gotten much traction yet:
https://bugs.ecmascript.org/show_bug.cgi?id=698

Norbert



More information about the es-discuss mailing list