time: Time.String() can return "+0000 +0000" as time zone

[calmh]

jb@syno:~ $ cat test.go 
package main

import (
    "fmt"
    "time"
)

func main() {
    t, _ := time.Parse("2006-01-02 15:04:05 -0700", "2015-07-13 12:13:14 +0000")
    fmt.Println(t)

    t, _ = time.Parse("2006-01-02 15:04:05", "2015-07-13 12:13:14")
    fmt.Println(t)
}
jb@syno:~ $ go version
go version devel +b6ead9f Tue Jul 7 21:53:11 2015 +0000 darwin/amd64
jb@syno:~ $ go run test.go
2015-07-13 12:13:14 +0000 +0000
2015-07-13 12:13:14 +0000 UTC
jb@syno:~ $ 

I guess this is due to

When parsing a time with a zone offset like -0700, if the offset corresponds to a time zone used by the current location (Local), then Parse uses that location and zone in the returned time. Otherwise it records the time as being in a fabricated location with time fixed at the given zone offset.

in Parse...? However, perhaps the fabricated location for +0000 should be UTC? It also seems system specific, as http://play.golang.org/p/NYpETX_L9a actually prints UTC in both cases.

(Dates returned from database/sql, at least with the github.com/lib/pq driver, suffer from this so it's not only synthetic.)

[ianlancetaylor]

The playground acts differently because the local time zone for the playground is UTC.

I think the package is acting as documented. The question is whether we should change time.Parse to treat a timezone of +0000 as meaning UTC.

[calmh]

Yeah, I'm not sure why the default format includes the time zone twice (date doesn't, on my system), but the "+0000 +0000" at the end of timestamps at least looks untidy.

[rsc]

This is working as intended. The default output is making sure to print the name and the zone offset of the location. In this case they're the same. It would be weird if some locations printed fewer fields.

[calmh]

I don't think I was asking for fewer fields, merely if the default/empty location +0000 should in fact print as UTC, as this is equivalent and less surprising?

[nrjones8]

@rsc @calmh @ianlancetaylor did anything ever come of this? I ask because I'm running into a similar issue (posted on Stack Overflow about it if it's helpful to see), though I think I now understand why. I was seeing inconsistencies with how an RFC 3339 time was interpreted on my local machine vs. on a CI server (and on the Go Playground). Please bear with my examples to see if I understand correctly!

(1) "2017-08-15T22:30:00+00:00" is interpreted as having 0 hour offset. If the system's local time has a 0 hour offset (such as UTC), then the Location in the parsed time.Time value has UTC as its location string. If the system's local time has any other offset, then the Location has an empty string for its location string. This is suggested by this line in the docs of Parse:

When parsing a time with a zone offset like -0700, if the offset corresponds to a time zone used by the current location (Local), then Parse uses that location and zone in the returned time. Otherwise it records the time as being in a fabricated location with time fixed at the given zone offset.

Since the CI server in question has its time set to UTC (as does the Go Playground), then UTC is set to be the location. Since my local machine does not have its timezone set to UTC, a "fabricated" location is set.

(2) 2017-08-15T22:30:00Z is interpreted as being UTC no matter what; the Z carries both the fact that there is a 0 hour offset, and that it is in UTC. Parsing such a string works the same way on my local machine as our CI server and the Go Playground.

Those two examples are shown here: https://play.golang.org/p/mYkMhS9sJT (with the output I see on my local machine included).

If all of that is correct, I guess my last question is: is +00:00 supposed to imply UTC? I'm assuming someone else has thought harder about this before, but I was a little confused by the wording in RFC 3339 here:

This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time.

Thanks for the help!

[davecheney]

Please do not hold discussions on closed issues, nobody will see them.
We don't the issue tracker to ask questions. Please see https://golang.org/wiki/Questions for good places to ask.

[nrjones8]

Whoops, sorry about that, thanks for pointing me to the right place! Will ask there instead.