Re: FAQ Topic - What does the future hold for ECMAScript? (2009-04-12)



In comp.lang.javascript message <gs1g7m$edl$1@xxxxxxxxxxxxxxxxxxx>, Tue,
14 Apr 2009 01:07:16, Garrett Smith <dhtmlkitchen@xxxxxxxxx> posted:

A dated draft will quickly fall out of date.

http://www.ecma-international.org/memento/TC39-M.htm

Not very quickly; they should not change it until well after July, and,
when they do, I expect someone here can tell us. And if the link text
is "Final Draft ECMA-262 5th Edition / April 2009" it will be valid as
long as the URL works.

Looking at TC39-M.htm and where they meet, one suspects it has no
substantial international aspect - they don't even visit Canada AFAICS.
That page does not contain "8601", but mentions JSON support : see
below.



What displeases me about ECMAScript's handling of ISO8601 is that it
seems to pretend that ISO8601 is just one format.


Looking at the ISO8601 format they've used, it looks like they switched
"," for "." to delimit the milliseconds.

| 15.9.1.15 Date Time string format
| The Simplified ISO 8601 format is as follows:
| YYYY-MM-DDTHH:mm:ss.sssTZ

Shouldn't that be a comma?

ISO 8601, interpreted, likes the comma, sneers at the full stop, but has
found it necessary to allow the latter. AFAIK, no-one uses the comma as
a decimal separator within data processing, though it can be used at the
human interface. It's sensible to be able to match that part with
\d\d\.\d\d\d and convert that string to a number with unary + instead of
having to handle it as two fields.


They include the omission of the "T", but only with the method
toUTCString, and only if an implementation does not have a "preferred
human-readable format").

toUTCString is not intended to be ISO. We should deprecate it, as being
unpredictable.


I now believe, without evidence, that JSON soundly chose that format as
having all the advantages of the corresponding ISO format and being as
accurate as possible (XML has the same but with ?[up to]? 7 decimal
places); but, being illiterate, chose to call the tail end TZ ; and that
ECMA provide that method with only JSON support in mind. I do not
suspect ECMA of having read ISO 8601.

My feedback to ECMA, Web page recently referred to, will include the
observation that the method should be renamed using JSON instead of ISO.


Note that their Date.parse must read it, but apparently is not required
to read anything similar ; it can be implemented by an exact RegExp test
prefixed to the existing Date.parse.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
.