proposal: time: use big-endian/ISO reference time

[akavel]

(I couldn't find an existing issue mentioning this, so I wanted to submit it for consideration for Go2, to make sure that whatever the final decision, it's at least given proper thought and not overlooked purely by accident.)

Proposal

I propose that for Go2, the "reference time" used by time.Format and time.Parse is changed to:

2001-02-03 16:05:06-0700

alias Feb 3 16:05:06 -0700 2001.

Rationale

This has the advantage of being trivial to remember for the whole world, not only U.S. residents, as well as being generally simpler in idea, following the "network order" (a.k.a. big endian), and straightforwardly corresponding to the universally (?) known international standards of RFC 3339 / ISO 8601.

The old reference time AFAIU is more or less accidental, per Rob's 2014 comment:

The choice was made by the output of the date command on my Unix
machine. I should have realized the format varies with locale. Mea
culpa. [...]

I believe Go2 is a point where this can potentially be approached, disarming somewhat the (AFAIU) main (and only?) rejection argument of "it's too late, this ship has sailed".

Alternatives

• time: Go should support Dec 31, 23:59:05, 1999 as an alternative format date #9696 — "Dec 31, 23:59:05, 1999"

[ianlancetaylor]

Is there any reliable way we could update existing code to continue working? Presumably we could do it for constant strings, but what variables? How common is that case?

[akavel]

One option for variables: maybe there could be an extra package (possibly not in stdlib), which would convert Go1 format to Go2 at runtime. Nontrivial usages could be automatically rewritten to use the conversion function (e.g. time.Format(oldtime.Preformat(somefmt)))

[bcmills]

Is there any reliable way we could update existing code to continue working?

In #20757 (comment) I suggested a go1time compatibility package. If we were to take that approach, go1time.Parse could use a separate format from time.Parse, although that could potentially cause confusion during the transition: given an untyped string constant, it would be difficult to tell whether it is a Go 1 format string or a Go 2 one.

[akavel]

Is it expected that the rewriter tool might be run on Go2 code and that it must NOP in such case? (Because if not, then IIUC any string passed to time.Format/time.Parse can be assumed "Go 1 format string".)

[ianlancetaylor]

We could introduce new functions with a different reference string, but I don't see any feasible way that we could change the reference string used by the current functions, even in a time/v2 package. Closing this issue.