Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
calmh opened this issue Jul 14, 2015 · 7 comments
Closed

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

calmh opened this issue Jul 14, 2015 · 7 comments
Labels
FrozenDueToAge
Milestone
Unplanned

Comments

@calmh
Copy link
Contributor

calmh commented Jul 14, 2015 

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
Copy link
Contributor

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.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 14, 2015
@calmh
Copy link
Contributor Author

calmh commented Jul 14, 2015

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
Copy link
Contributor

rsc commented Nov 4, 2015

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.

@rsc rsc closed this as completed Nov 4, 2015
@calmh
Copy link
Contributor Author

calmh commented Nov 4, 2015

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
Copy link

nrjones8 commented Aug 24, 2016 •
edited

@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
Copy link
Contributor

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
Copy link

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

@golang golang locked and limited conversation to collaborators Aug 24, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@davecheney @rsc @calmh @nrjones8 @ianlancetaylor @gopherbot