Ecma262: Standardize Date.prototype.toString further?

[littledan]

Across multiple JS implementations, it seems that Date.prototype.toString writes the timezone (in parens) in a long, locale-dependent form on Windows, but in a short form (2-4 letters) from the tz database on Unix-based OSes. More details in the V8 bug tracker.

The spec is really light on details for Date.prototype.toString:

Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.

Does anyone have a good memory of why this is the definition? Looks like it goes all the way back to ES1.

Fortunately, it seems that, at this point, implementations have converged on something that's almost always the same, with the exception of the timezone string.

For the timezone string, would it be a good idea to pick one of the two alternatives and standardize it across all platforms? Does anyone have evidence one way or the other whether either of the two is likely to be more web-compatible, or whether we need to preserve the variation?

[littledan]

Crazy idea: what if we standardized on omitting the parenthized "readable" timezones, leaving just the preceding GMT+-... This would be analogous to IS08601. As @anba pointed out Firefox has had a bug where it omitted many of these timezones already, so maybe the web would be able to handle the loss.

[jungshik]

Crazy idea: what if we standardized on omitting the parenthized "readable" timezones, leaving just the preceding GMT+-... This would be analogous to IS08601. As @anba pointed out Firefox has had a bug where it omitted many of these timezones already, so maybe the web would be able to handle the loss.

Might work, but shouldn't we standardize to 'UTC...' instead of 'GMT...'?

[jungshik]

Another alternative is

UTC+-.... (Olsaon Timezone ID with "_" replaced for a space for the readability)

For instance, UTC-0400 (America/New York)

Modern platforms would have Olson timezone ids handy so that implementation wouldn't be hard.

[littledan]

@jungshik

Might work, but shouldn't we standardize to 'UTC...' instead of 'GMT...'?

Well, you'd think so, but it seems like all browsers are shipping printing it as GMT, so I'm not sure if it would be web-compatible to change that.

For instance, UTC-0400 (America/New York)

I like this idea. It might be more likely to work on the web than just omitting that text because it preserves some parenthesized text with something that's vaguely human-readable inside. I don't think we should be adding tons of features to Date, but this seems relatively appropriate, intuitively.

Any other thoughts? cc @maggiepint

[jungshik]

Might work, but shouldn't we standardize to 'UTC...' instead of 'GMT...'?

Well, you'd think so, but it seems like all browsers are shipping printing it as GMT, so I'm not sure if it would be web-compatible to change that.

It looks like I have to live with GMT forever. I really hate to see GMT linger on 40+ years after its 'dethroning'. :-)

[ljharb]

@littledan given the Temporal proposal, and your own arguments against this OP in the recent meeting, should this be closed?

[littledan]

This is about finding some kind of full agreement between browsers on semantics of a method, not about adding features to Date or specifying an aspect of it partially.

[ljharb]

OK, what are the next steps?

[littledan]

Well, we would need a champion to take this on and try to drive us to certain semantics, figuring out what could be web-compatible somehow. I would be happy to mentor someone here, but I will not be able to drive this myself at the moment.