Re: [whatwg] Date Update?

On 1/19/14, Norbert Lindenberg <ecmascript@lindenbergsoftware.com> wrote:
>
> 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.
>
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?

http://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:
> 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
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io

Received on Monday, 19 May 2014 18:34:35 UTC