Discuss
  • FW: stepping on toes with toISOString

FW: stepping on toes with toISOString

# David-Sarah Hopwood (16 years ago)

Allen Wirfs-Brock wrote:

Also if Stockton is correct that the T is now optional in the ISO standard, I'd suggest making it optional in ES a well. Or, if optional is too much trouble, forbidding T and requiring a space instead. A small change, but the timestamps are so much nicer without the T! And it would be a shame for ES to get stuck with the T while ISO and everyone who uses it moves away from the T.

+1. With a space instead of the T, the format is actually reasonably pleasant to read.

# William Edney (16 years ago)

Allen -

Here's a link to ISO 8601:2004(E):

isotc.iso.org/livelink/livelink/4021199/ISO_8601_2004_E.zip?func=doc.Fetch&nodeid=4021199

Section 4.3.2:

"The character [T] shall be used as time designator to indicate the
start of the representation of the time of day component in these expressions."

this is then followed by:

"NOTE By mutual agreement of the partners in information interchange,
the character [T] may be omitted in applications where there is no risk of confusing a date and time of
day representation with others defined in this International Standard."

In addition I found IETF RFC3339:

tools.ietf.org/html/rfc3339

Section 5.6

"NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character."

So this leaves us in a bit of a bind. The 'out' for the 'T' provided
in the ISO8601 spec says that 'by mutual agreement of the partners in
information interchange'... (the T can be omitted).

Unfortunately, I think that's impossible given the nature of the Web.
I could produce an 8601 date without the 'T' in JS, but then transmit
it to any one of hundreds of thousands of servers that are running
software that expects it. There is no way to have 'mutual agreement'
amongst a potentially infinite set of folks using ISO8601.

Therefore, unfortunately (because I agree with David about readability
and would like to be able to +1 this), I have to give this a -1 and
recommend that we go with the spec 'conservatively' and enforce the 'T'.

# Allen Wirfs-Brock (16 years ago)

Arguably, the "mutual agreement" would be between Data.prototype.toISOString and Date.prototype.parse which are the only specified producers and consumers of this specific format. But I agree that it is probably better to require the "T". If somebody wants a more readable timestamp it is easy enough for them to replace the "T" with a blank.

# Daniel Friesen (16 years ago)

Just a random comment from someone outside.

I saw one library at one point which which rather than picking, just picked a default and used a strict parameter which would allow someone to pass true or false to chose "T" or " ";

Also rather than just toISOString it supported .toISOTimeString, .toISODateString and a .toISOString which was based on it.

When I came up with prototypes to add for MonkeyScript (still just drafting) I followed that same idea: draft.monkeyscript.org/api/_std/Date.html

((Of course, I'll modify the MonkeyScript drafts to comply with anything standardized for ES5))

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [daniel.friesen.name]