Sorry, that's time.Local = time.UTC. On Wed, Aug 24, 2016 at 8:26 PM Matt Harden <matt.har...@gmail.com> wrote:
> 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.
