Time conversion issue from UTC epoch to UTC date

Orekit usage
1

Hi all,

I have a “29s” issue on time conversions when using Orekit. I’m reading orbital data that I get with a UTC epoch and when converting this epoch to a date I get the right date but with a 29s offset compared to the value I get on various websites.

To convert from the epoch to the date I do this:

// Convert UTC epoch to UTC date
AbsoluteDate utcEpoch = new AbsoluteDate(1970, 1, 1, 0, 0, 0.0,TimeScalesFactory.getUTC());
AbsoluteDate date = new AbsoluteDate(utcEpoch, FastMath.round(utcTimeStamp));

Here are the different values I get:

UTC epoch: 1754391012
Orekit date: 2025-08-05T10:49:44
Date from various websites: 2025-08-05T10:50:13

I tried 3 different scenarios and always get this 29s offset… would any of you have an idea of why?

Thank you very much for your help!

Kind regards,

Benoist

2

Yes, this is expected. In fact, I guess you don’t have a 29s offset, but rather a 28.999918s offset.

Orekit UTC time scale follows IERS conventions. It is offset from a regular absolute time scale (TAI, Temps Atomique International). The offset was undefined before 1961, it was linear with offsets and slopes from 1961 until 1972 (offsets and slopes were adjusted so the final result was continuous), and it is offset by an integer number of seconds since 1972. The current offset (since 2017) between UTC and TAI is 37 seconds. The offset on 1970-01-01 was in the middle of a linear model, and the offset at that time was 8.000082 s. What you see is 37-8.000082=28.999918. You would see 27.999918s if your date was between 2015-07-01 and 2017-01-01 because during this time range the offset was 36 seconds and not 37 seconds, and so on for earlier dates.

I suppose the utcTimeStamp you use comes from some other source that uses Unix timestamp. This scale is not UTC, is intentionally and explicitly ignores leap seconds, and it assumes all days are exactly 86400s long.

If your input data follows these assumptions, instead of using new AbsoluteDate(utcEpoch, FastMath.round(utcTimeStamp)), your should use new AbsoluteDate(utcEpoch, FastMath.round(utcTimeStamp), TimeScalesFactory.getUTC()). This special constructor intentionally forget about discontinuities, so it should use the same assumptions as the Unix timestamp.

2 Likes
3

Hi Luc,

Thank you very much for the clear and thorough answer, I think it is spot on! Always a tricky topic these conventions I find… now I finally have my lost seconds back :sweat_smile:

Benoist