[lozf]

Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps.

Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West.

The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is used, should be the last character in a zero-offset (UTC) timestamp. However a UTC timestamp may instead be represented by a numeric offset of +00:00 hours.

The issue is that Go has, I believe misinterpreted the RFC and so presents the example timestamp:

    2006-01-02T15:04:05Z07:00 

which has a Z (meaning UTC), and then an ambiguous offset from it.

In that example the "Z" should be a "-" as all the examples are set in the Mountain Standard Timezone. RFC-3339 is quite clear that numeric offsets should be prefixed by either a "+" or a "-", or that a "Z" may be used instead when there is no offset.

An issue [1] was raised on their Github, the first post of which explains the problem clearly, but somehow the replies got distracted with whether the colon in numerical offsets is optional or not, and was subsequently closed.

[0]: https://tools.ietf.org/html/rfc3339#section-5.6 [1]: https://github.com/golang/go/issues/31113

[lann]

Go has an unusual way of specifying date formats. The "example" timestamp is a format spec and I believe the 'Z' will correctly handle offset signs.

From the docs:

Replacing the sign in the format with a Z triggers the ISO 8601 behavior of printing Z instead of an offset for the UTC zone.

[lozf]

There are several standards that specify how offsets should appear, but only Go uses Z (meaning Zero offset, aka UTC equivalent) followed by what appears to be a _positive_ number to represent a _negative_ offset...

By this logic we can expect to see a Moscow time stamp represented as HH:MM:SS+03:00 in every other program, and HH:MM:SSZ-03:00 only in Go.

It's just wrong, for no good reason.

[lann]

You are misunderstanding what you are seeing. The Z does not represent a literal Z in parsing/formatting.

https://play.golang.org/p/Qp-bBtzKpG-

[lozf]

OK, Thanks for clearing that up.

[viraptor]

> will end up with badly formatted timestamps.

I'm not sure why you think that. If rfc3339 format is required, then either a custom formatter can be created or a 3rd party lib can be used. Go may be silly in its stdlib, but it doesn't stop you from doing the right thing.

[lozf]

It turns out that although the examples aren't great, actually Go does do the right thing, so my mistake, as explained by lann some hours ago.