time: set specific rule for Date on daylight savings transitions

[jleben]

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

go1.7.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH=""
GORACE=""
GOROOT="/usr/lib/go-1.7"
GOTOOLDIR="/usr/lib/go-1.7/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build628236315=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1

What did you do?

I called time.Date for March 11, 2018, 2:00 AM, and printed the resulting time.
https://play.golang.org/p/N-XUwlGxpaF

What did you expect to see?

March 11, 2018, 2:00 AM is the moment when the clock in Vancouver changes to 3:00 AM due to switching from PST to PDT. So I would expect one of the following:

• Either 2:00 is interpreted in PST, and the time printed is 2:00 PST
• Or 2:00 is interpreted in PDT, and the time printed is 2:00 PDT

What did you see instead?

Instead, time.Date apparently interprets 2:00 in PDT, but prints 1:00 PST.

[odeke-em]

/cc @robpike @rsc

[crvv]

2018-03-11 02:00:00 America/Vancouver doesn't exist.
Neither 2018-03-11 02:00:00 PST nor 2018-03-11 02:00:00 PDT can be observed in time zone America/Vancouver.

Go chooses PDT to parse time, which is not wrong.
2018-03-11 02:00:00 PDT is 2018-03-11 01:00:00 America/Vancouver, which is 2018-03-11 01:00:00 PST.

I don't think this is a bug.

[ianlancetaylor]

The specific time does not exist. The documentation for time.Date says "In such cases, the choice of time zone, and therefore the time, is not well-defined. Date returns a time that is correct in one of the two zones involved in the transition, but it does not guarantee which." So this is working as documented.

[jleben]

I would like this issue to be reopened, as I have reasons other than those addressed in the comments above.

Specifically, I am not saying that the behavior does not conform to the documentation and is therefore a bug. I am saying that I'd like to see a stronger guarantee from the library, beyond what is currently documented.

More specifically, my issue is with the library interpreting the input in one time zone, but printing the time in another time zone. I would prefer if it printed the same time zone as the one in which it interprets the input.

To reply to some of the comments above: 1:00 PST does not "exist" in precisely the same way as 2:00 PDT does not exist. The library therefore has no more reason to print the former and not the latter from that perspective. However, there is another reason to prefer printing 2:00 PDT - the fact that that's how it interpreted the input in the first place.

[jleben]

You can think of this as a feature request rather than a bug report if you wish. So, rather than being convinced that this is not a bug, I need to be convinced that this is not a useful feature.

To support my claim that this is a useful feature, think of the following analogy. Imagine a program that can answer any question asked in any natural language. Suppose you ask that program in English: "Is the Earth round?" How happy would you be with the program providing the answer: "Oui"?

By analogy, I would like the library to print the resulting time in the timezone in which it intepreted the input, to avoid surprises.

[ianlancetaylor]

Neither 2:00 PDT nor 2:00 PST exist. The time goes from 1:59:59 to 3:00:00.

The time package is using the same location to look up the time and to return the time: that location is the one you loaded, America/Vancouver.

You are asking the time package to represent a time that simply doesn't exist. Probably the best response would be to return an error--that is what the Unix date command does--but unfortunately the time.Date API does not provide for an error return. I believe that the function is doing the best it can, and I believe it is behaving as documented.

I think you may be operating under a misapprehension that the time package is first picking PDT or PST and then looking up the time in that zone. That's not what it does. It actually first calculates the time without regard to timezone, then looks up the timezone offset for that time in the selected location, and then adjusts the time by that offset. Since the time 2:00 does not exist on that day on that location, the result is unpredictable, just as the documentation says.

[jleben]

I do not agree.

The documentation says:

Date returns a time that is correct in one of the two zones involved in the transition, but it does not guarantee which.

In order to explain conformance of the behavior to the documentation, you have to explain what "correct" in the quote above means.

The way I understand the documentation is that time.Date creates a time that conforms to the arguments according to one of the two possible interpretations of the arguments. Specifically, given the time and the location in the arguments, it is possible to interpret the arguments in the PST time zone or the PDT time zone.

Please note again what I already stated above: the time printed by the library is 1:00 PST, which does not exist any more thant 2:00 PDT exists.

Also, my apprehension about how the time package is implemented, and how it is actually implemented, has nothing to do with this argument: I am discussing the interface of the time package, not the implementation.

[ianlancetaylor]

Perhaps I'm completely confused, but why do you say that 1:00 PST does not exist? As far as I can tell, it does. The times before 2:00 are PST. The times 3:00 and after are PDT.

[jleben]

I agree with the following though: returning an error would make sense, and would be less surprising than the current behavior.

[ianlancetaylor]

Unfortunately we can't change the API, due to https://golang.org/doc/go1compat.

[jleben]

Oh, you're right, the time 1:00 PST does indeed exist. Sorry.

Okay, I see how the documentation should be interpreted now: by "correct in one of the time zones" it probably means "exists in one of the time zones."

Still, I think the behavior is rather surprising, and the documentation doesn't help much. If an error can not be returned, then I would at least like a stronger guarantee from the documentation as to how the input to Date is interpreted.

I am concerned, because the Date function may be used in contexts where calling it for a time that "does not exist" is not necessarily an end-user error. I have opened this issue because of the surprising behavior of the Concourse time resource. There, the user requests a task to be executed, for example, daily at 2:00 AM in Vancouver. When this time is passed on to time.Date, the result will be predictable on all days except on the day when the daylight savings time begins or ends. This could be improved if the behavior of time.Date had a stronger guarantee about how such time is handled.

[ianlancetaylor]

Any thoughts on what that guarantee could look like?