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

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

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

Comments

Projects
None yet
6 participants
@calmh
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

This comment has been minimized.

Show comment
Hide comment
@ianlancetaylor

ianlancetaylor Jul 14, 2015

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.

Contributor

ianlancetaylor commented Jul 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@calmh

calmh Jul 14, 2015

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@rsc

rsc Nov 4, 2015

Contributor

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.

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 Nov 4, 2015

@calmh

This comment has been minimized.

Show comment
Hide comment
@calmh

calmh Nov 4, 2015

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@nrjones8

nrjones8 Aug 24, 2016

@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!

nrjones8 commented Aug 24, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@davecheney

davecheney Aug 24, 2016

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.

Contributor

davecheney commented Aug 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nrjones8

nrjones8 Aug 24, 2016

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

nrjones8 commented Aug 24, 2016

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.