time: Date not handling location as it was in previous versions of go

[lockwobr]

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

$ go version
go1.13 darwin/amd64

Does this issue reproduce with the latest release?

yes, seems to be in 1.13.x currently.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/brian/Library/Caches/go-build"
GOENV="/Users/brian/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/brian/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/brian/software/knock/data-services/go.mod"
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/g0/633mr_rd6bvbx4g3__1hk7tc0000gn/T/go-build973777294=/tmp/go-build -gno-record-gcc-switches -fno-common"
$ uname -a

Darwin brians-MacBook-Pro.local 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
osx version 10.14.6 (18G95)

What did you do?

https://play.golang.org/p/1-gK7cWKVEO

package main

import (
	"fmt"
	"time"
)

func main() {

    loc, err := time.LoadLocation("America/Los_Angeles")
    fmt.Println(err)
    expected := time.Date(0, time.January, 1, 12, 34, 56, 789000000, loc)
    
    fmt.Println(expected)
}

What did you expect to see?

1.13 you get

<nil>
0000-01-01 12:34:56.789 -0752 LMT

What did you see instead?

1.12.7 you get

<nil>
0000-01-01 12:34:56.789 -0800 PST

[ianlancetaylor]

Do you see a change in behavior on the exact same machine?

[ianlancetaylor]

Oh, never mind, I know what this is. This is due to the fix for #30099. We used to mishandle dates before December 13, 1901, like the date you are testing in the year 0. Now we handle them correctly according the version of the tzdata database on your system. The standard tzdata records that the U.S. switched from local time zones (LMT == Local Mean Time) to what are now the standard timezones in 1883, so dates before 1883 are recorded as being in LMT. The offset for LMT in America/Los_Angeles is -7:52:58, which is why you are seeing these odd results.

Basically, timezones for very old dates are not very useful.