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: add microseconds-based APIs #16087

Closed
pmarks-net opened this issue Jun 16, 2016 · 20 comments
Closed

time: add microseconds-based APIs #16087

pmarks-net opened this issue Jun 16, 2016 · 20 comments

Comments

@pmarks-net
Copy link
Contributor

@pmarks-net pmarks-net commented Jun 16, 2016

The upper bound of a nanoseconds-since-1970 timestamp is not very far away, on the timescale of human civilization:

time.Unix(0, math.MaxInt64)
2262-04-11 23:47:16.854775807 +0000 UTC

Suggestions for improvement:

  • Document the limits at https://golang.org/pkg/time/, and deprecate the UnixNano function.
  • Create a UnixMicro function, which works until the year 294247.

I notice a lot of code that tries to implement UnixMicro as UnixNano()/1000, so it would be good to have a centralized, correct implementation.

@griesemer
Copy link
Contributor

@griesemer griesemer commented Jun 16, 2016

For Go25.

@ianlancetaylor ianlancetaylor changed the title Time.UnixNano will overflow in the year 2262 time: UnixNano will overflow in the year 2262 Jun 16, 2016
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jun 16, 2016
@adg
Copy link
Contributor

@adg adg commented Jun 17, 2016

I don't understand the complaint. This limitation is built into the design, and is why time.Unix first takes a seconds argument followed by a nanoseconds argument for precision.

time.Unix(math.MaxInt64, 0) represents the year 219250468, so I think this API is solid for the foreseeable future.

@adg
Copy link
Contributor

@adg adg commented Jun 17, 2016

Oh, I see. This is about UnixNano.

Note the docs already cover this:

The result is undefined if the Unix time in nanoseconds cannot be represented by an int64.

@adg adg closed this Jun 17, 2016
@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Jun 17, 2016

The documentation should specify what the limits are, because the actual values can be surprising to people who assume that int64 is practically infinite. It seems bad to promote a time format which is more restrictive than YYYY without spelling out the risks.

And what about creating a microseconds interface? I haven't tested the following code yet, but you can observe that the conversion functions are nontrivial in both directions:

return time.Unix(usec / 1000000, (usec % 1000000) * 1000)

return t.Unix() * 1000000 + int64(t.Nanosecond() / 1000)

@adg
Copy link
Contributor

@adg adg commented Jun 17, 2016

Who uses microseconds (apart from JavaScript)?

@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Jun 17, 2016

"Microseconds since 1970" a very common format within Google at least. Bigtable and Spanner are among the more prominent users.

@adg adg changed the title time: UnixNano will overflow in the year 2262 time: add microseconds-based APIs Jun 17, 2016
@adg
Copy link
Contributor

@adg adg commented Jun 17, 2016

Seems like something worth considering.

@extemporalgenome
Copy link
Contributor

@extemporalgenome extemporalgenome commented Jun 24, 2016

I don't see why we would deprecate the UnixNano method. The argument seems to be that time.Now().UnixNano() will be undefined when run ~246 years from now. By the same argument, time.Now().UnixMicro() will also be undefined in a mere ~292231 years.

There's no point in deprecating UnixNano, so this proposal should only be concerned with weighing the benefit of adding UnixMicro.

@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Jun 24, 2016

Notice that Unix() returns int64, not int32. Had it been the latter, it would make sense to argue for its deprecation. In order-of-magnitude terms, UnixNano() is only marginally better than a 32-bit unix timestamp.

We're obviously going to have a bad time when 9999 rolls around, but designing a format that can't even get that far seems like an obvious mistake.

@uluyol
Copy link
Contributor

@uluyol uluyol commented Jun 24, 2016

Whatever software is around in 200 years can spend 46 years migrating to storing 128-bit timestamps. This sounds like a documentation bug if anything.

The few people who need a UnixMicro can write a trivial function.

@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Jun 24, 2016

The few people who need a UnixMicro can write a trivial function.

But the function is not trivial, and in practice most people get it wrong. UnixNano()/1000 gives you the worst of both worlds, with regards to range and precision.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 24, 2016

I think we should postpone this issue until Go has a int128 type.

@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Aug 11, 2016

Why should adding microseconds-based APIs be blocked on an int128 type? If time.UnixNano128(...) and t.UnixNano128() existed, then microseconds-based APIs would no longer be necessary.

@minux
Copy link
Member

@minux minux commented Aug 14, 2016

@nathany
Copy link
Contributor

@nathany nathany commented Aug 18, 2016

re: int128 is issue #9455

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 18, 2016

@nathany, I think @ianlancetaylor's int128 comment was a joke. He's saying that by the time we have an int128 type (distant future), only then would we care about the year 2262, and if we had an int128 anyway, then we wouldn't need to do anything in this issue, because nanoseconds would again be sufficient.

Jokes are funnier when they're explained, I know. Sorry.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 18, 2016

I didn't really mean it to be a joke as such. I mean more or less what @bradfitz says, but seriously. Assuming Go continues to exist at all, it will get an int128 type at least a century before 2262. There is no need to introduce a microsecond API, we just need to change the time package to use int128.

@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Sep 23, 2016

The first bullet point (document the limits) was fixed by https://go-review.googlesource.com/#/c/28478/

@rsc
Copy link
Contributor

@rsc rsc commented Feb 3, 2017

The time.Time representation itself has no problem with the year 2262, by design. Conversions like t.UnixNano exist for interoperability with other systems that use those encodings. They are not fundamental to the API, just helpful when you need that conversion. Google programs that use UnixNano()/1000 can keep doing so. I agree with the various comments that we can fix this in 200 years (with plenty of time to spare) by changing the result of UnixNano to int128. Until then, now that the documentation makes the limitation clear, I think we can close this issue.

@rsc rsc closed this Feb 3, 2017
@pmarks-net
Copy link
Contributor Author

@pmarks-net pmarks-net commented Feb 3, 2017

For the record, I don't think "changing the result of UnixNano to int128" is possible, because of all the existing code that assumes the result is an int64. This will almost certainly require a new API, like UnixNano128().

@golang golang locked and limited conversation to collaborators Feb 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.