On 1/19/14, Norbert Lindenberg ecmascr...@lindenbergsoftware.com wrote:
On Jan 19, 2014, at 10:01 , Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Sunday, January 19, 2014, Garrett Smith dhtmlkitc...@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
