time: Now() and time.unixTime() do not call setLoc, causing timezone to not be nil when system time is UTC

[sbuss]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version devel +4cce27a3fa Sat Jan 21 03:20:55 2017 +0000 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/usr/local/google/home/sbuss/workspace"
GORACE=""
GOROOT="/usr/lib/google-golang"
GOTOOLDIR="/usr/lib/google-golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build194178423=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you do?

When running go code in a system set to UTC, or by setting time.Local = time.UTC, golang does not correctly set loc to nil when either time.Now() or time.Unix() are called. You can reproduce the issue via this play link.

What did you expect to see?

I expected the timestamps generated by Now() to have loc = nil, as stated by the docs on time.Time

What did you see instead?

The timestamps actually have this weird Location: &{UTC [] [] %!s(int64=0) %!s(int64=0) %!s(*time.zone=<nil>)}

[gopherbot]

CL https://golang.org/cl/38002 mentions this issue.

[cespare]

@sbuss note that the "docs" you linked to are comments on an unexported field of time.Time, not part of the public documentation of the type.

---

I've also noticed this in the following context: if you have a test that creates a timestamp with time.Now(), round-trips it through, say, JSON, and then compares the result to the original timestamp using == (or more commonly via reflect.DeepEquals where the timestamp is buried in some other structure), the test will pass unless the local tz offset is +0 (because the non-nil location round-trips to nil).

In this case the fix is to not write tests that use == on time.Times. But it is an interesting gotcha.

[ianlancetaylor]

I'm not persuaded. I don't think the time package needs to cater to people who explicitly set time.Local = time.UTC. And I don't think the time package makes any promises about the unexported loc field for the case where the local timezone happens to be UTC.

If we're going to make this change, it needs a better rationale than I see so far in this description. For example, it needs an explanation in terms of something else that matters and can be clearly understood, like #15716.

[sbuss]

I don't think the time package needs to cater to people who explicitly set time.Local = time.UTC

I included time.Local = time.UTC in the play link because I thought it'd be better to be explicit. But this also happens if your system timezone is set to UTC, like the golang playground: https://play.golang.org/p/sP141RpCuF

I've also noticed this in the following context: if you have a test that creates a timestamp with time.Now(), round-trips it through, say, JSON, and then compares the result to the original timestamp using == (or more commonly via reflect.DeepEquals where the timestamp is buried in some other structure), the test will pass unless the local tz offset is +0 (because the non-nil location round-trips to nil).

This is exactly how I discovered this issue, in fact. I was storing and retrieving some data to Google Cloud Datastore and doing a reflect.DeepEqual on the before-and-after. This manifests as the time you put into datastore not equaling the time you get from datastore. I know that users are supposed to use time.Equal, and we've since updated our tests, but the simple patch in the linked CL does fix some surprising behavior.

[cespare]

@ianlancetaylor well, more or less the same justification as #15716 applies here (it could be phrased as "Time.MarshalJSON and Time.UnmarshalJSON aren't symmetrical if the local timezone is UTC"):

package main

import (
	"fmt"
	"log"
	"time"
)

func main() {
	t0 := time.Now()
	s := t0.Format(time.RFC3339Nano)
	t1, err := time.Parse(time.RFC3339Nano, s)
	if err != nil {
		log.Fatal(err)
	}
	fmt.Printf("t0==t1: %t\n", t0 == t1) // true, unless the location is UTC
	fmt.Printf("t0: %#v\n", t0)
	fmt.Printf("t1: %#v\n", t1)
}

https://play.golang.org/p/xx0fU4gn45

The commit message for 5fbf35d that fixed #15716 is relevant.

/cc @rsc

[ianlancetaylor]

@cespare Thanks, I'm fine with fixing that problem, but then let's update the CL to be about that problem, with an appropriate test, rather than a test that explicitly sets Local = UTC.

[sbuss]

but then let's update the CL to be about that problem, with an appropriate test, rather than a test that explicitly sets Local = UTC.

SGTM I will do this tomorrow

[sbuss]

While trying to write the test you recommended, I discovered another potential bug in the time marshaling functions (#19502). I'll wait until learning more in that bug before revising my patch for this issue.

Edit: I figured out that that was intended behavior and know how to do this correctly. Should have a new patch soon.

[sbuss]

I can't write a test which uses MarshalXYZ or UnmarshalXYZ because I have to disable the monotonic clock via AddDate(0, 0, 0), which calls setLoc and effectively masks the bug. So I can't meet your ask exactly, @ianlancetaylor, but the code snippet from @cespare is close enough that I'll go with that.

[sbuss]

Actually, I can't use @cespare's code snippet, either, because of the same issue with the monotonic clock. You'll always get different structs if the monotonic clock isn't disabled, but the act of disabling it hides the bug. @ianlancetaylor Is there something else I could do to the patch or tests to make you more in favor of it?

Note that this issue doesn't show up on the golang playground yet because it's running a version of go that doesn't include the monotonic clock.

[cespare]

If we consider the test example, in Go 1.9 it will fail in all timezones; there's nothing special about UTC. So the motivation here kind of goes away. Perhaps we should just leave it alone.

[ianlancetaylor]

I believe you can use t.Round(0) to get the same value without a monotonic time and without calling setLoc.

[sbuss]

I believe you can use t.Round(0) to get the same value without a monotonic time and without calling setLoc.

Yup, that did it. Thanks for the pointer!

I just posted an updated patch which tests round trips through the Marshal/Unmarshal functions explicitly. Without the fix to Now and unixTime, the new test fails like this:

--- FAIL: TestDefaultLocNow (0.00s)
        time_test.go:1275: Now() and Now().UTC() behave differently for MarshalBinaryRoundTrip
        time_test.go:1275: Now() and Now().UTC() behave differently for GobEncodeRoundTrip
        time_test.go:1275: Now() and Now().UTC() behave differently for MarshalJSONRoundTrip
        time_test.go:1275: Now() and Now().UTC() behave differently for MarshalTextRoundTrip
        time_test.go:1275: Unix(...) and Unix(...).UTC() behave differently for MarshalBinaryRoundTrip
        time_test.go:1275: Unix(...) and Unix(...).UTC() behave differently for GobEncodeRoundTrip
        time_test.go:1275: Unix(...) and Unix(...).UTC() behave differently for MarshalJSONRoundTrip
        time_test.go:1275: Unix(...) and Unix(...).UTC() behave differently for MarshalTextRoundTrip

rather than a test that explicitly sets Local = UTC

I don't know how I'd affect the local timezone of the test runner without explicitly setting Local = UTC. Do you have a suggested way of doing this?

[ianlancetaylor]

For testing purposes I suspect we need a new function like initTestingZone that sets the local location name to "UTC", just as initLocal does.

Seems like another way to fix this problem is to change MarshalJSON and friends to not use RFC3339Nano but instead use "2006-01-02T15:04:05.999999999-0700".