1

In my Java task I get some timestamps in Strings in the format of: YYYY-MM-ddTHH:mm:ss.S. These timestamps are supposed to be interpreted as TAI time (International atomic time).

I need to compare these timestamps to others, some of which might be UTC times. Therefore I want to convert the TAI times to UTC times (or UNIX time). Now my problem is, that I can't find an option which allows me to parse the timestamp Strings without interpreting the (TAI) time in a wrong timescale.

For example using the standard LocalDateTime would interprete the timestamp as time including leap seconds, if I understood it correctly. Now I could try adding the seconds via an ZoneOffset, but I don't know how I would calculate these without already knowing/ having the correct date and time in either timescale.

I also looked at ThreeTen-Extra, which supports TAI time, but here they only allow parsing from TAI seconds. I am not able to change the input format to get the representation as TAI seconds.

How should I go forward from this?

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
gumitmu
  • 11
  • 2
  • 1
    Parse them as if they're UTC, then add the appropriate number of seconds based on the date? (Presumably as these are TAI values, you don't need to worry about them ever representing leap seconds themselves.) – Jon Skeet Aug 09 '23 at 15:18
  • How do the [`convert…`](https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/scale/UtcRules.html) methods in *ThreeTen-Extra* not accomplish your goal? – Basil Bourque Aug 09 '23 at 16:01
  • 1
    @JonSkeet At first glance, it seems the [`convert…`](https://www.threeten.org/threeten-extra/apidocs/org.threeten.extra/org/threeten/extra/scale/UtcRules.html) methods in *ThreeTen-Extra* do just that, using the leap second count in effect at the moment of interest. – Basil Bourque Aug 09 '23 at 16:04
  • The conversion methods would work, if I were able to get a TAI Instant with the correct date and time. The problem is, that the creation of the TAI Instant needs a different input format, and the creation of a UTC Instant with the same input would falsify the time, since the leap second difference would be ignored. But I guess I could use the getLeapSecondsAdjustment method to get the leap seconds to add as JonSkeet suggested. Thank you all for helping. – gumitmu Aug 10 '23 at 07:50
  • Didn't use the getLeapSecondAdjustment but getTaiOffset method. – gumitmu Aug 10 '23 at 08:33
  • Does this work using Three-Ten Extra? (1) Define the TAI epoch as `TaiInstant taiEpoch = TaiInstant.ofTaiSeconds(0, 0);`. (2) Calculate the duration since the TAI apoch on the local time line since it hasn’t got leap seconds either. (2.a) `LocalDateTime taiEpochLocal = taiEpoch.toInstant().atOffset(ZoneOffset.UTC).toLocalDateTime();` (2.b) `Duration durSinceTaiEpoch = Duration.between(taiEpochLocal, LocalDateTime.parse("2016-01-01T12:00:00.0"));`. (3) Add the duration to the epoch: `TaiInstant taiTimestamp = taiEpoch.plus(durSinceTaiEpoch);`. – Ole V.V. Aug 10 '23 at 10:16
  • Result from my attempt using the example input string from the previous comment is `1830340810.000000000s(TAI)` corresponding to `2016-01-01T11:59:34Z` UTC. It looks 26 seconds early compared to the input string because there were 26 leap seconds from 1972 to 2016. – Ole V.V. Aug 10 '23 at 10:18

0 Answers0