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: AddDate(0, 0, 1) gives the same exact day in Samoa edge case #29602

Closed
VictorDegliame opened this issue Jan 7, 2019 · 3 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@VictorDegliame
Copy link

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 agnivade changed the title time.AddDate(0, 0, 1) gives the same exact day in Samoa edge case time: AddDate(0, 0, 1) gives the same exact day in Samoa edge case Jan 8, 2019
@agnivade agnivade added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jan 8, 2019
@agnivade agnivade added this to the Go1.13 milestone Jan 8, 2019
@agnivade
Copy link
Contributor

agnivade commented Jan 8, 2019

/cc @rsc @bradfitz

@iwdgo
Copy link
Contributor

iwdgo commented Mar 24, 2019

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..

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@ALTree
Copy link
Member

ALTree commented Dec 4, 2019

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.

@ALTree ALTree closed this as completed Dec 4, 2019
@golang golang locked and limited conversation to collaborators Dec 3, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants