[whatwg] Date Update?
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: 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:
- www.ecma-international.org/ecma-402/1.0/#sec-12
- norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat
- 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: ecmascript#698
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: 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: www.ecma-international.org/ecma-402/1.0/#sec-12, norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat, 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. But now you're talking about formatting, and can't help but strongly disagree with what you've written.
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).
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).
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 and ends on 2014-03-01, then the element is positioned 10/31 of the way into january and at the beginning of March.
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.
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?
lists.w3.org/Archives/Public/public-script-coord/2014AprJun/0051.html
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: ecmascript#698
Sure, but the ECMAScript 5 got ISO-8601 wrong by stating:
| The value of an absent time zone offset is "Z" 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. people.mozilla.org/~jorendorff/es6-draft.html#sec
On 5/19/14, 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: 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: www.ecma-international.org/ecma-402/1.0/#sec-12, norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat, 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. But now you're talking about formatting, (I meant to say that you're talking about parsing).
[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: 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: www.ecma-international.org/ecma-402/1.0/#sec-12, norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html#DateTimeFormat, 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] www.joda.org/joda-time/apidocs/org/joda/time/LocalDate.html [2] 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] norbertlindenberg.com/ecmascript/intl.html#sec-12.3.3
With to associating time zones with dates, see the discussions [4] and [5].
[4] esdiscuss/2013-February/thread.html#28847 [5] esdiscuss/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: ecmascript#698
Sure, but the ECMAScript 5 got ISO-8601 wrong by stating:
| The value of an absent time zone offset is "Z" 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. 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
On 5/25/14, Norbert Lindenberg <ecmascript at lindenbergsoftware.com> wrote:
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:
[...]
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.
Locale-sensitive for event view/CrUD by users in multiple timezones.
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.
The start and end dates are shown in the UI. Locale-sensitive display is needed for CrUD with multiple timezones and users in multiple timezones.
Given a logged-in user with an application-stored timezone:
Backend (BE) stores events in UTC. Event dates are transmitted as an ISO string, local to that event, to the user.
5pm CA --> 12am UTC
12am UTC --> 8am China
We're in DST here.
Even when the CA user is travelling to Hawaii, the event starting from 5pm in CA time is displayed in the app as 5pm, and not 8pm (which will be shown on his system clock at that moment).
Question: If the even starts at 2am and ends immediately after 3 am, on May 9, how long is it?
I want something like:
zonedDate.setTimezoneOffset("America/New_York")
This would allow the user to change start and end times and the duration would be correct.
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?
No, the element is positioned ten thirty-firsts of the way through that month; the month is an LI element, and yes; that's background info.
Operating systems already have ways to let the user select their time zones,
Hopefully they're not so limited as the UI they display. Macs to miss a lot of cases. E.g. Navajo Nation. (Probably it should be named Macbook Amateur.
| The function returns a new object whose properties | and attributes are set as if constructed by an object | literal assigning to each of the following properties the | value of the corresponding internal property of this | DateTimeFormat object (see 12.4): locale, calendar, | numberingSystem, timeZone, hour12, weekday, era, | year, month, day, hour, minute, second, and timeZoneName. | Properties whose corresponding internal properties are | not present are not assigned.
Does it allow me to get a TZO or just the timezone back?
dateObj.getTimezoneOffset("America/Shiprock") would fit what I need.
You mixed lexical grammar ("object literal"), properties of an object, and behavior in a very confusing paragraph. I reread it a bunch of times but can't squint my brain quite right enough to grok it. hourNo0 seems like something to force midnight to be zero, but instead it mentions 11 vs 12.
Other problems: Timezones cannot be referred to as static offsets. If that lets me set an IANA timezone and then add that to a calendar, and then calculate the correct tzo based on an ISO local date format.
DST rules change and ES5 allows implementations to apply the changes proactively/retroactively. That's unreliable.
ES5 ISO implementation is broken.
IANA timezones account for leap seconds. ECMA forbids leap seconds. How do you intend to reconcile this?
Garrett,
I'm cc'ing es-discuss, as that's a more appropriate list for discussing updates and extensions to the language's built-in objects.
On Sunday, January 19, 2014, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
Just some random ideas on JavaScript Date. I understand that it was copied from Java. Was this based on the requirement to “look like Java” on the typical appeal to popularity marketing tact? (Java was hot back then).
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: javascript.spec.whatwg.org/#dateAny proposals for Date.prototype.format, ala strftime?
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.Any proposal to get the user's preferred date format?
Garrett, I'm cc'ing es-discuss, as that's a more appropriate list for discussing updates and extensions to the language's built-in objects. Rick On Sunday, January 19, 2014, Garrett Smith <dhtmlkitchen at gmail.com> wrote: > Hi All - > > Just some random ideas on JavaScript Date. I understand that it was > copied from Java. Was this based on the requirement to “look like > Java” on the typical appeal to popularity marketing tact? (Java was > hot back then). > > 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? > > 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. > > Any proposal to get the user's preferred date format? > -- > Garrett > @xkit > ChordCycles.com > garretts.github.io > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140119/c3bf22ba/attachment.html>