go: time: MarshalBinary fails on valid Time

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

$ go version
go version go1.14.2 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/path/Library/Caches/go-build"
GOENV="/Users/path/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOOS="darwin"
GOPATH="/Users/path/code/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/opt/go/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/opt/go/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bf/vxlr89hd4jqfx43ncc0y10b00000gn/T/go-build493699043=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Call In on a zero value time.Time creates in valid time when the result would be before the zero time.

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

What did you expect to see?

The zero value time would have its time zone set to the specified timezone yet still be the zero value date.

For Example: Setting 0001-01-01 00:00 UTC to EDT should return 0001-01-01 00:00 EDT or return an error if the value is outside the range (which in this case it is)

Using zeroTime.After(newTime) should return true or some other mechanism to check the time is valid should exist.

What did you see instead?

A time value before the range was returned with an invalid time zone 0000-12-31 19:03:58 -0456 LMT.

Attempting to compare the result against the zero time using After does not function as zeroTime.After(newTime) and newTime.After(zeroTime) both return false so you can have a false positive that the time is valid.

Also the resulting time value prevents MarshalBinary from working

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 15 (8 by maintainers)

Commits related to this issue

Most upvoted comments

Yes, the main crux is MarshalBinary doesn’t support local mean time at the moment.

Some Info:

Part of the problem is with changing the time zone for values before time zones existed. If you look at the output of t2 you will see the minutes and seconds are no longer 0 and the timezone becomes some fractional local mean time.

Which looks to be based on when US railways adopted time zones: https://en.wikipedia.org/wiki/Time_zone#cite_ref-8

(Adding the above to the documentation for In would help reduce confusion especially for people not versed in US railway history 😄 )

I guess the question of: Should we maintain historic accuracy or expected behavior? If the user asks for US/Eastern then returning LMT is confusing without any error.