[whatwg] Date Update?

Norbert Lindenberg ecmascript at lindenbergsoftware.com
Sun May 25 19:51:34 PDT 2014


[Dropping whatwg@ and public-script-coord@ since this appears to be an ECMAScript issue.]

On May 19, 2014, at 11:34 , Garrett Smith <dhtmlkitchen at gmail.com> wrote:

> On 1/19/14, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:
>> 
>> 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.
>> 
> I was talking about formatting, not parsing.

Both, actually.

> But now you're talking
> about [parsing], and can't help but strongly disagree with what
> you've written.

I guess you mean the statement “that most applications prefer date-and-time pickers, so we dropped parsing”?

I should have clarified my assumption that we’re talking about locale sensitive parsing, since your case below appears to be about locale independent parsing.

> Case:
> 
> Server sends back JSON that is used to build a calendar component or
> Gantt chart
> 
> The application parses the start and end of the times given over the
> JSON (and I have some JSON in the application that I am developing
> right now; see below).

Since the start and end times are parsed by the application (and not directly presented to the user), they should be represented in a locale independent form. If they’re just points in time, you can use either a JSON number representing the time value of a Date object, or a JSON string in ECMAScript Date Time String Format with “Z”. If not, please clarify your requirements.

> After the JSON is parsed, UI components, what I've dubbed "timeline
> events" get created and added to the requisite year (created and
> added, filling in any elided years as necessary). (The year calendar
> element happens to be a UL with LI for each month).

This is where you might need new API if support for non-Gregorian calendars or time zones other than UTC and local is required.

> After the correct year element(s) are created, the timelineEvent can
> be added. Each timeline event has a startDate, an endDate, and a
> duration. The startDate is used to create and then to append the
> timelineEvent element to month of the year in which it appears, where
> its position is adjusted so that its position and placement appears
> exactly according to the dates and times specified. For example, if
> the event starts on 2014-01-01

2014-01-11, to match the 10/31 below?

> and ends on 2014-03-01, then the
> element is positioned 10/31 of the way into january and at the
> beginning of March.

This looks like background information – or do you see API requirements coming out of this?

>>>> 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.
>> 
> LocalDate object sounds really useful.

Do you mean LocalDate as provided by Joda-Time [1] and Java 8 [2], which per spec are not tied to time zones? Or do you mean a date associated with a time zone, as you discuss below?

[1] http://www.joda.org/joda-time/apidocs/org/joda/time/LocalDate.html
[2] http://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html

> How would that best be done? What is a good way determine a physical
> location and map that to a timezone, and have the timezone be
> associated with that date?

Operating systems already have ways to let the user select their time zones, sometimes assisted by location information from GPS, cell phone, or WiFi antennas and corresponding databases. The most recent draft of the next edition of ECMA-402 provides a way for an application to obtain the default time zone [3].

[3] http://norbertlindenberg.com/ecmascript/intl.html#sec-12.3.3

With regards to associating time zones with dates, see the discussions [4] and [5].

[4] https://mail.mozilla.org/pipermail/es-discuss/2013-February/thread.html#28847
[5] https://mail.mozilla.org/pipermail/es-discuss/2013-April/thread.html#29664

>> 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
>> 
> Sure, but the ECMAScript 5 got ISO-8601 wrong by stating:
> 
> | The value of an absent time zone offset is "Z"
> http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
> 
> ECMAScript draft 6 corrects this mistake:
> 
> | If the time zone offset is absent, the date-time is interpreted as a
> local time.
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-date-time-string-format

How does this relate to what I said? “Sure, but” seems to indicate some connection…

Norbert


More information about the es-discuss mailing list