Date.prototype.toISOString and fractional parts
On Aug 5, 2014, at 9:07 AM, Mameri, Fred (HBO) wrote:
According to the spec, the toISOString is currently defined to return a string in the format YYYY-MM-DDTHH:mm:ss.sssZ. Specifically, there’s a 3-digit fractional part introduced by a . (that’s the “.sss" above) appended to the seconds.
It is my understanding of the ISO8601 spec that fractional parts can start with either a dot or a comma, and that the number of digits in the fractional part needs to be agreed upon by both parties using that format. If my interpretation is correct, the current behavior seems to be problematic, in that if an API accepts more (or fewer) than 3 fractional digits, the result of this function needs to be further modified before they can be used against said API. Same goes for dot vs. comma.
The ECMAScript Date-time interchange format is based upon ISO8601 but is not ISO 8601. It was designed to ensure that ECMAScirpt implementations could reliably interchange date values formatted as strings. By specification, all conforming ES implementations agree that the separator is "." and that three fraction digits are required.
I don't see what we would gain from a ES-ES interchange perspective, from changing our Date toISOString format to allow a "," instead of a "." or a variable number of digits.
Finally, note that Ecma-402 defines an expanded set of Date formatting compabilities. It may be able to do this for out already.
Would it make sense then to augment the spec to have toISOString take optional parameters Date.prototype.toISOString([precision[, separator]])?
I prefer to leave parametric date formatting to Ecma-402.
According to the spec, the toISOString is currently defined to return a string in the format YYYY-MM-DDTHH:mm:ss.sssZ. Specifically, there's a 3-digit fractional part introduced by a . (that's the ".sss" above) appended to the seconds.
It is my understanding of the ISO8601 spec that fractional parts can start with either a dot or a comma, and that the number of digits in the fractional part needs to be agreed upon by both parties using that format. If my interpretation is correct, the current behavior seems to be problematic, in that if an API accepts more (or fewer) than 3 fractional digits, the result of this function needs to be further modified before they can be used against said API. Same goes for dot vs. comma.
Would it make sense then to augment the spec to have toISOString take optional parameters Date.prototype.toISOString([precision[, separator]])?