Note that ParseInLocation(..., time.UTC) should give you the same behavior in both test scenarios. If you have to use Parse, you can set time.Location = time.UTC, with the same result.
On Wed, Aug 24, 2016 at 10:05 AM <nrjon...@gmail.com> wrote: > Thanks for the response! > > On Wednesday, August 24, 2016 at 7:16:00 AM UTC-7, Ian Lance Taylor wrote: > >> On Tue, Aug 23, 2016 at 10:58 PM, <nrjo...@gmail.com> wrote: >> > >> > I was running into issues with comparing time.Time objects in a unit >> test >> > that would pass on a CI server, but fail on my local machine. I wanted >> to >> > see if anyone could double check my understanding of how `time.Parse` >> treats >> > locations (I posted on Stack Overflow about it if it's helpful to see), >> > though I think I now understand why; I was initially confused by the >> fact >> > that `time.Parse` wasn't setting "2017-08-15T22:30:00+00:00"'s timezone >> to >> > be UTC, since the docs for `time.Parse` read: "In the absence of a time >> zone >> > indicator, Parse returns a time in UTC." >> >> Note that timezones don't matter when comparing time.Time values, >> assuming you use the Equal method. >> > > Interesting, the test in question was using `reflect.DeepEqual`, which > explains why it failed. > > >> >> As far as Parse returning UTC, whether there is a timezone indicator >> or not is a function of the format string passed to Parse. It's not a >> function of the string being parsed. >> > > Ah yes, I really mean `Parse` with `time.RFC3339` as the format string > (the issue is actually coming from decoding a JSON string into a > `time.Time` field, which expects a quoted string in RFC 3339 format - so I > was conflating the two). However, I believe the implementation details of > `Parse` do seem to affect the timezone indicator. If the timezone of the > system happens to have the same offset as the offset present in the string > being parsed, then the timezone indicator is set to the timezone of the > machine; if not, it's a "fabricated location" with an empty string. So > parsing the same string (and using the same format string) on different > machines will return different timezone indicators. > > >> >> >> > I thought 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), but came up with a few examples that may explain the >> behavior I >> > was seeing. 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. >> >> Sounds right. >> > > Thanks for clarifying, this is the crux of what I had been confused by. > > >> >> > (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: >> >> No. A "Z" in the string being parsed implies UTC. +00:00 implies the >> zero offset, which may have daylight savings time. >> >> At least, that is my understanding. >> > > I see. For context - the `time.Time` I'm trying to parse is part of a JSON > blob being created by PHP code and sent to a Go app. It appears (perhaps > not shockingly) that PHP has a different interpretation of RFC 3339's > serialization of a UTC timestamp, and just tacks on the "+00:00" instead of > "Z." See this gist > <https://gist.github.com/nrjones8/0a625aa8d07c94a582fc1517b04b0b15> for > an example. Sigh. > > Nick > > > >> >> Ian >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
