time: now.Before(time.Unix(math.MaxInt64, 0)) should return true

[gopherbot]

by tim.olsen@10gen.com:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. run program at http://play.golang.org/p/cvez19tXfE

What is the expected output?
"Cool, not the end of the world yet"


What do you see instead?
"uh oh"


Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
darwin (Mac OS X 10.8.4

Which version are you using?  (run 'go version')
go version go1.1.2 darwin/amd64

Please provide any additional information below.
Subtracting 1 or 1000 from MaxInt64 does not change the behavior.  Dividing by 2 does
however suggesting time.Time cannot accommodate the last bit (before the sign) of int64
when converting from unix epoch time.

[remyoudompheng]

Comment 1:

This falls into the general topic of integer overflow handling in time package.

[robpike]

Comment 2:

As Rémy says, there are overflow issues in the implementation of the time package.  A
comprehensive analysis is required.
But also: to avoid overflow the package sometimes clamps values, which can lead to
surprises too, especially if such values are then used in arithmetic.
It might be necessary to rethink the internals a bit.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

[rsc]

Comment 3:

Labels changed: added go1.3maybe.

[rsc]

Comment 4:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 5:

Labels changed: added repo-main.