time: RFC3339 timestamps are wrongly formatted #34725
Labels
Comments
|
I have just been told that the Z in the example timezone isn't actually a literal Z when formatting/parsing -- if that's true this issue can be closed, although a bit more clarification in the documentation would be appreciated. "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. Thus:" and it's few examples (all in the same -7 hours offset) wasn't particularly clear. |
|
Sorry, I was misled by non-working examples of Go code, and have since discovered that I was wrong, not you guys, so closing this now. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Please refer to the first post in Issue #31113 which was closed after getting distracted about whether colons in numerical offsets are optional.
The actual issue is with the Z followed by an offset.
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, based on military use of the phonetic alphabet, hence "Zulu" time), 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.
I believe Go has misinterpreted the RFC and so presents the example timestamp:
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.
Putting an offset after the Z only makes things more confusing, as not only is it wrong, but it has what appears to be a positive number for what is actually a negative offset.
The text was updated successfully, but these errors were encountered: