Integer overflow with parse_rfc3339_ns

[morgante]

Short description

If you attempt to parse a date in the far future, parse_rfc3339_ns returns a negative number (I assume caused by integer overflow).

Example:

b := "9999-12-31T23:59:59Z"
b_v := time.parse_rfc3339_ns(b)

    "b_v": -4852116232933722000,

Expected behavior

I expect it to either raise an error or return the correct number.

[anderseknert]

Ah, seems like the max (9223372036854775807) for the int64 data type used by Go is passed after 9276-12-03 .. we can at least be happy we won't be around to deal with all the systems crashing at that date ;)

I guess raising an error would be the right thing to do here, unless we'd want to replace all the calls to time functions with something that handles later dates.

[srenatus]

I guess raising an error would be the right thing to do here, unless we'd want to replace all the calls to time functions with something that handles later dates.

I'd propose a non-halting built-in error. It's what we do with weird inputs in other places. It'll cause the builtin to go undefined, and raise an error if running with "strict builtin errors" enabled. (We could really use #3742.)

[anderseknert]

Interestingly, the docs on time.UnixNano says the following:

UnixNano returns t as a Unix time, the number of nanoseconds elapsed since January 1, 1970 UTC. The result is undefined if the Unix time in nanoseconds cannot be represented by an int64 (a date before the year 1678 or after 2262). Note that this means the result of calling UnixNano on the zero Time is undefined. The result does not depend on the location associated with t.

I'm not sure in what way they mean the result is undefined.. I guess that's what's undefined 😄 But if that's the case we might want to take even that into account.

[tsandall]

I agree with @srenatus here--I think that the function should generate a non-halting error in this case. That should be a relatively small change. Moving it into the plan for the next release.