From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: July 6, 2011 10:08:38 AM PDT
To: Lasse Reichstein <reichsteinatwork@gmail.com>
Cc: es5-discuss@mozilla.org
Subject: Re: Extended Date Time String years and toISOString/parse
good points for clarification in future editions
On Jul 4, 2011, at 3:47 AM, Lasse Reichstein wrote:
>>ES5.1 specificaiton of Date Time String formats allow an extended signed-six-digit format for years outside of 0000..9999.
>> It's not clear whether "the ability to specify 6 digit years" only applies to parsing, or whether toISOString should also generate extended years for dates outside the four-digit range. I'm guessing it should (otherwise the behavior of toISOString isn't specified at all).
agreed, toISOString should generate the extended year format when appropriate. The conditions for the RangeError should probably be expended to include any time value that can not be represented using extended year format.
>>I.e., is it a requirement that new Date(DATE.UTC(10000,0,1)).toISOString() is "+010000-01-01T00:00:00.000Z"?
that was the intent
>>Also, if the date is invalid, but follows the format of a Date Time String, e.g., "1972-02-30", are there any requirements on the behavior of Date.parse on that string?
In general, if a data doesn't conform to the "ISO date" rules in 15.9.1.15 then Date.parse is allowed to fall back on implementation specific rules for processing the string. It isn't clear from the spec. language whether any semantic constraints on the the number of days in a month are to be considered. However, if we assume that such semantic restrictions on day in month are are intended then an invalid date such as "1972-02-30" presented to Date.parse would still fall back to an implementation specific interpretation and hence might be accepted.
It isn't obvious to me whether or not it is worthwhile including such days-in-month restrictions in the spec. "valid" dates work the same regardless and the actual result for invalid dates would remain implementation specific.
>>(As a side note, the "hh" field isn't specified the way the remaining ones are ... I assume it's supposed to be 00..23 - as opposed to HH which is 00..24, but since it's signed it could also be 00..12).
ISO 8601 also doesn't seem to be explicit in this regard.
Because ES5.1 uses HH rather than hh in describing the timezone offset I think we need to interpret it as meaning 0..24
>>/L 'And pedantically, YYYY is the decimal digits of the year in the *proleptic* Gregorian calendar!'
true
>>--
>>Lasse Reichstein - reichsteinatwork@gmail.com
_______________________________________________
es5-discuss mailing list
es5-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es5-discuss
It's actually implicitly stated that toISOString() should be able to return a string in extended years format.
From 15.9.4.2 Date.parse (string)
---
If x is any Date object whose milliseconds amount is zero within a particular implementation of ECMAScript, then all of the following expressions should produce the same numeric value in that implementation, if all the properties referenced have their initial values:
x.valueOf()
Date.parse(x.toString())
Date.parse(x.toUTCString())
Date.parse(x.toISOString())
---
If toISOString() wouldn't return a string with extended years, the statement about "same numeric value" couldn't apply.
fixed in rev20 editor's draft
Added a range error within toISOString if year can't be represented using the ISO format (including extended years)
clarified that Date.parse does handle ISO extended years.
fixed in rev20 draft, Oct. 28, 2013