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

Comments

Projects
None yet
@pmarks-net
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2016

Who uses microseconds (apart from JavaScript)?

@pmarks-net

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2016

Seems like something worth considering.

@extemporalgenome

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2016

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

@pmarks-net

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Member

commented Aug 14, 2016

@nathany

This comment has been minimized.

Copy link
Contributor

commented Aug 18, 2016

re: int128 is issue #9455

@bradfitz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 23, 2016

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

@rsc

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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.
You can’t perform that action at this time.