Re: [go-nuts] time: time.Parse's Location

2016-08-24 Thread Matt Harden
Sorry, that's time.Local = time.UTC. On Wed, Aug 24, 2016 at 8:26 PM Matt Harden 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 2

Re: [go-nuts] time: time.Parse's Location

2016-08-24 Thread Matt Harden
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 wrote: > Thanks for the response! > > On Wednesday, August 24, 2016 at 7:16:00

Re: [go-nuts] time: time.Parse's Location

2016-08-24 Thread nrjones8
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, > > 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 ma

Re: [go-nuts] time: time.Parse's Location

2016-08-24 Thread Ian Lance Taylor
On Tue, Aug 23, 2016 at 10:58 PM, 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 o

[go-nuts] time: time.Parse's Location

2016-08-24 Thread nrjones8
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