W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

Re: [whatwg] Date Update?

From: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>
Date: Sun, 19 Jan 2014 16:30:50 -0800
Cc: Norbert Lindenberg <ecmascript@lindenbergsoftware.com>, Rick Waldron <waldron.rick@gmail.com>, WHAT Working Group <whatwg@lists.whatwg.org>, public-script-coord <public-script-coord@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-Id: <390539C0-8575-48B0-8F9B-96792AF588D9@lindenbergsoftware.com>
To: "Jasper St. Pierre" <jstpierre@mecheye.net>, Garrett Smith <dhtmlkitchen@gmail.com>

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

> On Sunday, January 19, 2014, Garrett Smith <dhtmlkitchen@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
Received on Monday, 20 January 2014 00:31:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:51 UTC