2

Edit below with summary of answer:

I'm trying to understand a bit more about java.time.Instant and leap seconds. If I run this:

System.out.println(Instant.ofEpochSecond(60*60*24*365*50));

I expected to create a time/date that's near the start of 2020-being 50 lots of 365 days after Jan 1, 1970, so allowing for a bunch of leap years, a few days short. I do indeed get such a date. So far so good.

The date/time I get shows as 2019-12-20T00:00:00Z. What I'm surprised by is that I thought the result would also be a few seconds shy of midnight, due to leap seconds. But it's exactly midnight UTC.

Am I misunderstanding leap seconds, or java.time.Instant (or perhaps something else entirely!)?

EDIT: as commenters have pointed out, Java time isn't required to do anything about leap seconds, probably because Unix time ignores them, and the reason for that is called out in a Wikipedia article and indirectly through another question. The crux seems to be that future leap seconds aren't predictable, but get added when astronomers agree the Earth has slowed enough to warrant it. And it seems that that slowing is not predictable.

Note, I didn't delete my question since the association between Unix time and java time is not mentioned in the question that others referred to, so I believe this adds something of some small merit.

Thanks for the input!

Toby Eggitt
  • 1,806
  • 19
  • 24
  • 3
    Does this answer your question? [Unix time and leap seconds](https://stackoverflow.com/questions/16539436/unix-time-and-leap-seconds) - Wikipedia explains it as well: https://en.wikipedia.org/wiki/Unix_time - basically, Unix time ignores leap seconds. – CryptoFool Oct 26 '20 at 18:46
  • 3
    As the documentation says: "Implementations are therefore not required to actually perform the UTC-SLS slew or to otherwise be aware of leap seconds" – Andy Turner Oct 26 '20 at 19:03
  • Oh, wow, yes, that makes sense. Seems remarkable that such a complex and seemingly powerful API would fail to implement this in its reference form. But I guess the "we don't know about future leap seconds" piece is a good rationale. – Toby Eggitt Oct 26 '20 at 19:15
  • Also ordinary computer clocks don’t know leap seconds, so (1) you would not have the accuracy anyway (2) you would need special logic to convert between computer clock and current instant around leap seconds. I happen to think that they made the right choice. – Ole V.V. Oct 26 '20 at 20:21
  • Interesting observation. I was looking upon the NTP as that "special logic" since it nudges the clocks to represent the correct day-time even after a leap second occurs. But I'm realizing that I need to do more reading on the stuff underlying this, since it's clear to me that if we simply ad 86,400 seconds times a few thousand days and add that time to Jan 1, 1970 midnight UTC, we won't come to the "right time". But, I'm satisfied that no algorithm can compensate for things in the future that aren't predictable, so there's not much choice here. – Toby Eggitt Oct 28 '20 at 23:08
  • 1
    If you really want to measure/calculate seconds including leap secs then you can use my lib [Time4J](https://github.com/MenoData/Time4J). About `java.time`, [Oracle](https://github.com/threeten/threeten/issues/197) does not want to implement it and removed the data from the tzdb distribution. – Meno Hochschild Feb 18 '21 at 20:22

0 Answers0