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: Unix(sec, nanonsec) has bizarre undocumented behavior for large values of sec #10906

Closed
maxpoletto opened this issue May 19, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@maxpoletto
Copy link

commented May 19, 2015

The biggest value that can be passed as the first parameter of time.Unix(seconds, nanos) is
math.MaxInt64 - 62135596800. Sample code: http://play.golang.org/p/Ck5Ny1W-ud

62135596800 is the number of seconds, accounting for leap days, that separate the start of the Go internal epoch (year 1) from the start of the Unix epoch (1970).

time.Unix() should not leak its implementation details in this way, or else the behavior should be clearly documented.

It does not seem unreasonable, given the current spec/docs, for someone to create a time.Unix(math.MaxInt64, 0) as a sentinel value, but this leads to strange and hard-to-debug behavior.

@minux

This comment has been minimized.

Copy link
Member

commented May 19, 2015

@gopherbot

This comment has been minimized.

Copy link

commented May 19, 2015

CL https://golang.org/cl/10223 mentions this issue.

@minux minux closed this in f3fc8b0 May 19, 2015

@gopherbot

This comment has been minimized.

Copy link

commented May 20, 2015

CL https://golang.org/cl/10266 mentions this issue.

@mikioh mikioh changed the title time.Unix(sec, nanonsec) has bizarre undocumented behavior for large values of sec time: Unix(sec, nanonsec) has bizarre undocumented behavior for large values of sec May 20, 2015

@mikioh mikioh added this to the Go1.5 milestone May 23, 2015

minux added a commit that referenced this issue Jun 18, 2015

time: correct unrepresentable Unix time comment
It's easy for someone who wants a time bigger than any
valid time to reach for time.Unix(1<<63-1, 0), so it
makes sense to explicit say such value is not valid.

Fixes #10906 (again).

Change-Id: If71e32472ae40d86c30e629b982406040a73c4c7
Reviewed-on: https://go-review.googlesource.com/10266
Reviewed-by: Russ Cox <rsc@golang.org>

@golang golang locked and limited conversation to collaborators Jun 25, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.