time: time.LoadLocation returns incorrect time zone

[stishenok]

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

$ go version
go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?

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

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/stishenok/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/stishenok/go"
GOPROXY="direct"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/stishenok/go/src/github.com/test/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/8p/t619jr29323dksvz22f_5z400000gn/T/go-build839715032=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

import (
	"fmt"
	"time"
)

func main() {
	locAmsterdam, err := time.LoadLocation("Europe/Amsterdam")
	if err != nil {
		panic(err)
	}
	timeAmsterdam, err := time.ParseInLocation("15:04", "13:40", locAmsterdam)
	if err != nil {
		panic(err)
	}

	locBerlin, err := time.LoadLocation("Europe/Berlin")
	if err != nil {
		panic(err)
	}
	timeBerlin, err := time.ParseInLocation("15:04", "13:40", locBerlin)
	if err != nil {
		panic(err)
	}

	fmt.Println("Location : ", timeAmsterdam.Location(), " Time : ", timeAmsterdam)
	fmt.Println("Location : ", timeBerlin.Location(), " Time : ", timeBerlin)
}

What did you expect to see?

Location : Europe/Amsterdam Time : 0000-01-01 13:40:00 +0100 CET
Location : Europe/Berlin Time : 0000-01-01 13:40:00 +0100 CET

What did you see instead?

Location : Europe/Amsterdam Time : 0000-01-01 13:40:00 +0019 AMT
Location : Europe/Berlin Time : 0000-01-01 13:40:00 +0100 CET

[ALTree]

Thanks for reporting this. You are on 1.11, but I can reproduce the issue on go1.12 and on tip too, so it's not a recent regression.

It appears to be an issue in the parsing function. For example, the following:

package main

import (
	"fmt"
	"time"
)

func main() {
	timeFormat := "15:04"
	locs := []string{
		"Europe/Amsterdam",
		"Europe/Berlin",
		"America/Juneau",
		"Asia/Tokyo",
	}

	for _, loc := range locs {
		l, err := time.LoadLocation(loc)
		if err != nil {
			panic(err)
		}

		time, err := time.ParseInLocation(timeFormat, "13:40", l)
		if err != nil {
			panic(err)
		}
		fmt.Println(time.Location(), time)
	}
}

prints:

Europe/Amsterdam 0000-01-01 13:40:00 +0019 LMT
Europe/Berlin 0000-01-01 13:40:00 +0053 LMT
America/Juneau 0000-01-01 13:40:00 +1502 LMT
Asia/Tokyo 0000-01-01 13:40:00 +0918 LMT

note how the timezone info is completely wrong. But if I add the year to the time format, like this:

package main

import (
	"fmt"
	"time"
)

func main() {
	timeFormat := "2006 15:04"
	locs := []string{
		"Europe/Amsterdam",
		"Europe/Berlin",
		"America/Juneau",
		"Asia/Tokyo",
	}

	for _, loc := range locs {
		l, err := time.LoadLocation(loc)
		if err != nil {
			panic(err)
		}

		time, err := time.ParseInLocation(timeFormat, "2020 13:40", l)
		if err != nil {
			panic(err)
		}
		fmt.Println(time.Location(), time)
	}
}

Then it works fine:

Europe/Amsterdam 2020-01-01 13:40:00 +0100 CET
Europe/Berlin 2020-01-01 13:40:00 +0100 CET
America/Juneau 2020-01-01 13:40:00 -0900 AKST
Asia/Tokyo 2020-01-01 13:40:00 +0900 JST

[ALTree]

I was wrong, this is working as intended. Without a year, the default is the year 0000 and we can't really print meaningful timezone/zone offset info for that year. So Basically we print what the tzdata database has a the first recorded timezone and offset. This is a dup of #10297.

Closing, as this is not a bug.

[dhalman]

Without a year would it be reasonable to assume current year, same perspective as kitchen time? Being that omission = current rather than 0

[ianlancetaylor]

@dhalman This issue has been closed for months.

I don't think we should change the behavior of time.ParseInLocation at this point.

[dhalman]

Agreed! Just academically curious if there is ever an expected use case where the developer would plausibly want the current expected default behavior over the configured behavior.

No worries! Thanks for even responding :)