Support leap seconds

[Don-vip]

RTKLib Positioning Solution File (.pos) support has been added in #17829.

Right now JOSM considers date are expressed in ​UTC but in fact they're using ​GPS time.

They currently differ by 18 seconds (number of ​leap seconds added to UTC since 1980 UTC-GPS synchronization).

It's not easy to support leap seconds in Java because Java date/time classes don't support them.

The only Java libraries that support leap seconds are ​Time4J and ​threeten-extra.

[StephaneP]

It looks like ​Threeten-extra library support GPS Time too:
​https://coderanch.com/t/667087/java/Reconciling-Java-date-time-GPS

[stoecker]

Supporting leap seconds means constant updates every half year. Is this really necessary for JOSM?

[Don-vip]

Why half year? The latest leap second has been added in 2016.

[stoecker]

Leap seconds may or may not be added at 30.06. or 31.12. each year. It is not deterministic and announced approx. 6 months before by the IERS (​https://www.iers.org/SharedDocs/News/EN/BulletinC.html). So to make it right we need to create another admin task to get and check these announcements and update JOSM when necessary.

And all that for a value, which has no real meaning for JOSM.

[Don-vip]

We have a new major Java version every 6 months. The workload of checking if we must add a +1 in a text file is nothing compared to that. And it has a meaning for users like Stéphane. The coding part involves some work, but the maintenance is insignificant.

[stoecker]

Coding is easy. Store the files like this and simply apply the value of leap seconds: ​https://update.gnssonline.eu/leapseconds.cfg

[stoecker]

Algorithm for GPS conversion:

• Parse the list reverse (last entry first)
  • when date_to_fix >= leapdate+86400+leapseconds-19, subtract the leap seconds-19, done
  • if not try previous entry

Usually the last value is correct, so only one check is done.

Optimization: When parsing the file, already store date as "leapdata+86400+leapseconds-19" and the leap as "leap-19".

NOTE: Leap seconds may be negative or positive. That means either 23:59:59 is missing or 23:59:60 exists. ATM leaps have always been positive.

Above link can be used as data base. It will be updated by me as long as I'm responsible for the software using it.

[anonymous]

Just FYI, leap seconds can also be introduced in March and September (​https://www.iers.org/IERS/EN/Science/EarthRotation/UTC.html), but given the current interval rate it's highly unlikely that will happen anytime soon.

[simon04]

Ticket #19932 has been marked as a duplicate of this ticket.

[simon04]

The OpenJDK build includes the following file related to leap seconds from tzdata: ​https://github.com/openjdk/jdk/blob/master/make/data/tzdata/leapseconds

On GNU/Linux, the file is available under /usr/share/zoneinfo/leapseconds (Fedora).

For good test cases see ticket:17829#comment:19

[skyper]

This file is part of the package tzdata and the file name is a bit different on Debian:

-rw-r--r-- 1 root root 10666 Jan  9 19:59 /usr/share/zoneinfo/leap-seconds.list

[Don-vip]

Not sure we can rely on OS here. Windows has ​limited leap second support. It seems it can handle future leap seconds fine, but I can't retrieve past ones (before june 2018) using their tool:

w32tm /leapseconds /getstatus /verbose

[Secondes intercalaires]
Activé : 1 (Local)
Nombre de secondes intercalaires (après juin 2018) : 0 (local)
Liste des secondes intercalaires (local) :

Or maybe we can ship the list of leap seconds for the 1980-2018 period and rely on OS after that (need to check macOS support too).