On Jan 19, 2014, at 10:01 , Jasper St. Pierre <[email protected]> wrote:

> On Sunday, January 19, 2014, Garrett Smith <[email protected]> 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

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to