Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

time: incorrect timezone for dates after 2038 #36654

Open
bourbaki opened this issue Jan 20, 2020 · 8 comments
Open

time: incorrect timezone for dates after 2038 #36654

bourbaki opened this issue Jan 20, 2020 · 8 comments
Labels
Milestone

Comments

@bourbaki
Copy link

@bourbaki bourbaki commented Jan 20, 2020

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

$ go version
go version go1.13.4 darwin/amd64

Does this issue reproduce with the latest release?

Yes. See: https://play.golang.org/p/zhDzRup9BRP

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/artem/Library/Caches/go-build"
GOENV="/Users/artem/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/artem/parsec/fed:/Users/artem/parsec/fed/_vendor"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.4/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.4/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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/n0/2pcvtf912dz4qq61kl72vsg00000gn/T/go-build253354351=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

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

package main

import (
	"fmt"
	"time"
)

func main() {
	loc, _ := time.LoadLocation("America/Los_Angeles")
	d1 := time.Date(2037, 6, 3, 11, 0, 0, 0, loc)
	d2 := time.Date(2038, 6, 3, 11, 0, 0, 0, loc)
	fmt.Println(d1)
	fmt.Println(d2)
}

What did you expect to see?

2037-06-03 11:00:00 -0700 PDT
2038-06-03 11:00:00 -0700 PDT

This is behavior that has been produced by other time processing tools and libraries. For example:

$ TZ='America/Los_Angeles' date --date="@2159200800"
Thu Jun  3 11:00:00 PDT 2038

What did you see instead?

2037-06-03 11:00:00 -0700 PDT
2038-06-03 11:00:00 -0800 PST
@ianlancetaylor ianlancetaylor changed the title Incorrect timezone for dates after 2038 time: incorrect timezone for dates after 2038 Jan 21, 2020
@ianlancetaylor ianlancetaylor added this to the Go1.15 milestone Jan 21, 2020
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 21, 2020

This is happening because the time package does not consider the "extended" information that is available in the tzdata database.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 21, 2020

Change https://golang.org/cl/215539 mentions this issue: time: use extended time format past end of zone transitions

@beoran

This comment has been minimized.

Copy link

@beoran beoran commented Jan 21, 2020

2038 support is becoming more and more important, we only have 18 left years to get it right now. Already some future dates will start to fail. So I'm glad to see this is being fixed.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 21, 2020

But note that this particular fix, while worth doing, is somewhat speculative. We don't actually know what the daylight savings time transitions will be in 2038, and so reporting future times as PDT or PST is a guess. Since this particular example uses America/Los_Angeles, it's worth noting that California passed a referendum to stop doing daylight savings time transitions at all (https://ballotpedia.org/California_Proposition_7,_Legislative_Power_to_Change_Daylight_Saving_Time_Measure_(2018)) and that may still happen. If it does, the program above will report incorrect results, at least until the tzdata files are updated.

@tandr

This comment has been minimized.

Copy link

@tandr tandr commented Jan 21, 2020

Well, at least it should report a correct ("as of known today") time zone, and I understood your patch correctly, it does fix that.

What I kind of did not understand - will that code addition of extended tz info parsing slow down all time-related ops, or this happens "once" and that's it?

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 21, 2020

In the CL that I sent, it will slow down all timezone operations that involve dates in 2038 and later. It will not affect timezone operations for current dates.

My guess is that before 2038 the tzdata format will change to push the slowdown farther into the future. Anyhow, since nobody has complained about this until now, I assume that not too many people care about it, so let's start by getting it right, and only then worry about making it fast.

(My hope is that by 2038 we'll all stop using daylight savings time, and all of this code will become a peculiar historical artifact.)

@iWdGo

This comment has been minimized.

Copy link
Contributor

@iWdGo iWdGo commented Feb 12, 2020

The CL does not seem restricted to US time zones. Regarding European time (EU), the trend is to discontinue Daylight Saving Time in the coming years (cf. https://ec.europa.eu/transport/themes/summertime_en) although final decision does not seem available.

@DryHumour

This comment has been minimized.

Copy link

@DryHumour DryHumour commented Feb 13, 2020

But note that this particular fix, while worth doing, is somewhat speculative. We don't actually know what the daylight savings time transitions will be in 2038, and so reporting future times as PDT or PST is a guess.

As @ianlancetaylor points out, this is an inherent problem with trying to report future civil times. There is nothing to prevent the relevant authorities from changing the laws back and forth, potentially on multiple occasions. Technically some jurisdictions could even enact law that retroactively changes the interpretation of past times.... (Weirder things have happened. The tzdata files make fascinating reading.) More prosaically, the tzdata files can be updated or corrected post-facto.

In general, any attempt to make non-trivial use of a future civil time is fraught with difficulty. Making a best guess in displaying it is about as far as one should probably go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.