proposal: time: add "1136214245" as layout string for unix timestamp

[dpifke]

Proposal Details

2006-01-02T15:04:05Z07:00 as a UNIX timestamp (seconds since January 1, 1970) is 1136214245. (In milliseconds, it's 1136214245000; in microseconds, it's 1136214245000000; in nanoseconds, it's 1136214245000000000.)

I propose being able to use these values as layouts with time.Parse. For instance, the result of time.Parse("1136214245", "1707688329") would be Sun, 11 Feb 2024 21:40:11 GMT. These values are unambiguous with the current std string and I believe could be added in a fully reverse-compatible manner.

My motivation is that I have some library code which converts from fmt.Stringer (such as a field from JSON input data) to time.Time by guessing several common layouts. It currently special-cases situations where strconv.ParseFloat succeeds, and then tries to guess the appropriate unit. This could be simplified if the standard library supported these layouts.

[ianlancetaylor]

That strings seems pretty hard to remember. And it's already possible to call time.Unix and friends, as you mention. The case here doesn't seem compelling.

[dpifke]

TBH, after over 10 years of writing Go, I never remember 2006-01-02T15:04:05Z07:00 either, and usually have to refer to the time.Parse docs or use a constant like time.RFC3339. If this proposal passes, I would hope we'd add a similar constant as well.

[robpike]

This is a very odd request, asking a string parser to accept a purely numeric value. If you have the number, you don't need to parse it again.

Also, you should be using ParseUint not ParseFloat.

[dpifke]

The source data gets coalesced into a string because all of the possible source types implement fmt.Stringer. Yes, it is inefficient to have to convert it back to a numeric value, but there is no "Numberer" equivalent to fmt.Stringer in the standard library which supports taking an arbitrary type and returning a number.

ParseFloat was chosen because I see no reason to disallow fractional seconds. I'm fine if this proposal is accepted and we decide either a) those should not be allowed, or b) there should be a separate layout "1136214245.0" if they should be allowed.

Edit to add: I would love if all of my input was strongly typed, but for interoperability with JSON or YAML or CLI flags or other dynamic languages and configuration formats, you sometimes have to be liberal in what you accept. It is not uncommon to see a JSON file edited by a human which ends up with something like {number: "1234"}.

For another example, consider encoding/csv, which returns rows as []string. I frequently encounter CSV files containing timestamps in either UNIX format or ISO8601—very occasionally a mix of the two.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[clausecker]

It would be very useful to have some way to get a UNIX time stamp out of time.Format. Consider for example if an application lets the user supply a custom format string to produce time in the desired format. If the user wants to script the application, it may be desirable to use UNIX time. But current time.Format does not support this use case.

[Merovius]

I'll also note, that having a format-specifier doesn't just allow to parse a string consisting entirely of a number as a time - it also allows to use that format-specifier in a substring. For example, a git commit internally stores author/commiter information as e.g.

author Axel Wagner <mero@example.com> 1693893277 +0200

This proposal would allow a parser of this format to split off the name/email part and then call

time.Parse("1136214245 -0700", "1693893277 +0200")

to parse the time in the appropriate time zone. I actually ran into this many years ago, when trying to implement a puro-go git library.

I'm still not sure it's worth including, though. Also, I'll note that I disagree that this can be implemented in a fully backwards compatible manner:

time.Parse("1136214245", "1136214245")

Currently this returns an error "month out of range", while under this proposal, it would presumably return the reference time. In particular, it seems the layout-parser currently interprets the first "1" as the numeric month format specifier.