time: AddDate(0, 0, 1) gives the same exact day in Samoa edge case

[VictorDegliame]

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

$ go version
go version go1.11.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
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/me/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/me/gocode"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11.2/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11.2/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
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/tj/b6jfdlvn48n0k1jzb4vbdzmm0000gn/T/go-build284351641=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I was testing that my code was properly adding a day to a weird Samoa edge case where they skipped a day at the end of 2011 (2011-12-29 + 1 day is 2011-12-31).
https://play.golang.org/p/RomvXuHl3Pi

What did you expect to see?

Adding a day to 2011-12-29 in Samoa should give 2011-12-31 after normalization.

What did you see instead?

Adding a day to 2011-12-29 in Samoa normalizes down and thus gives exactly the same date and hour

Additional information

If we set the hour to 10am or above on 2011-12-29 in Samoa, this works fine.
https://play.golang.org/p/eOX7s2P10-u

[agnivade]

/cc @rsc @bradfitz

[iwdgo]

Icann refers to this behavior as the "date line correction" which is not implemented by the time package. For dates before the timezone creation, it defaults to UTC-10 in Pacific. The same behavior can be observed for Kiribati new timezone "Pacific/Kiritimati" which was created on 30 Dec 1994, i.e. next day is 1 Jan 1995 only at 10 AM..

[ALTree]

When given a non-existent timestamp, the time package has to fallback to a valid date somehow. This is also true for smaller jumps (like 1 hour). Since 2011-12-30 is Samoa does not exists, we fallback to the nearest valid dates (12-29 and 12-31).

This is documented in the Date and AddDate descriptions:

AddDate normalizes its result in the same way that Date does,

and Date:

A daylight savings time transition skips or repeats times.
For example, in the United States, March 13, 2011 2:15am never occurred,
In such cases, the choice of time zone, and therefore the time, is not well-defined.

Since this behaviour is expected and documented, I think we can close this issue.