Marcin 'Qrczak' Kowalczyk wrote:
You shift the responsibility without eliminating the problem. The program begins miscalculating the time when it's run 6 months after its author has updated the leap second table which the program uses.
Of course it's impossible to solve it. This means that conversion between TAI and UTC should be avoided when possible.
If the user wants to obtain UTC, doesn't mind a hiccup on leap seconds, and doesn't want to keep a leap second table up to date and arrange for a long-running program to reread it when it changes - he can set the system clock to UTC and the program should then interpret the system clock as UTC.
Why doesnt the library connect to one of the TAI clocks, and read the leap second table. If the system clock is UTC the system must be running NTP and be connected to a network. If it is not running NTP the system time is more or less TAI anyway (no leap seconds occur without a networked time reference and NTP) I would suggest having the library read the leap seconds table as part of the library, as leap seconds can only occur at the end of june or december, you have 6th months to update the table. Keean.