On Mon, Jul 25, 2016 at 7:56 AM, Martin Burnicki <[email protected]> wrote: > Tony Finch wrote: >> Martin Burnicki <[email protected]> wrote: >>> >>> IMO a better approach would be to let the system time run on TAI, and do >>> the conversion to UTC, and local time in the next step, by runtime >>> libraries. >> >> The kernel needs to know UTC for things like filesystem timestamps. > > I know. This is mainly to avoid ambiguities you'd have with time stamps > in local time, as under plain old DOS. > > Using TAI for the file time stamps should be fine as well, it would even > avoid ambiguities for files which are written during a leap second. Of > course, if the kernel could *tell* the time stamps are TAI instead UTC > then tools like 'ls' could display the TAI timestamps in UTC, if required.
This is a great idea, except it's impossible. :( The POSIX defined APIs are such that there's THE timestamp for the file and it's, by definition UTC. There's no way to say these files have a TAI timestamp and those have a UTC timestamp. And if it did, the impact would be huge. Make(1) would need to change to cope with the 40 second difference, as would many other programs that compare the system time to a file time or file times to each other. And then there's the external storage format requirement. Most systems specify UTC as the format, either directly or in a de-facto way because time_t is pretty close to UTC (technically UT(unspecified)). Third, you'd alway need to have current, perfect knowledge of leap seconds to start the system. Or you'd have to accept errors that flow from this. The first time you need to convert a UTC timestamp to TAI you'll have issues downstream if there was a leap second that you somehow missed. Do you have an API to tell others that you lied to them in the past and to correct things? Or do you live with the errors (errors designed in, which is a big problem with time_t today). And then there's a class of applications that deals in 'future times'. If your knowledge of leap seconds change after you've asked for a time to be converted from UTC to TAI then that TAI time is off by a second. or 40 if you lose your leap second table. This is a minor problem when running a well connected system, since timestamps more than a month in the future are rarely requested (but do sometimes happen) and usually you can propagate the new leap info before people start asking for it. But if not, what do you do? If you tell me "It's only a second error" I'm going to punch in the face. That's the same lousy attitude that's lead to the hodge-podge of half-assed almsot solutions that we have today. And then there's the 'cold spare' issue. If I have a deployed system that had a number of spares sitting on the shelf to be swapped in when the primary component fails, then those systems won't know the new leap second information when they first come up and will need to acquire it. In the case of a cold GPS receiver, this can takes minutes which delays the recovery of the system. In one system I deployed, we had to go to great lengths in this case to find the current leap information from other local systems (since we weren't connected to the internet). Otherwise, ships could run aground (it was a timing system for navigation control). And then there's the long running process issue. With the current time libraries, the tables are loaded at startup, but never again. So, if you have an application that needs to know about leap seconds, and you'd hope to use the timezone files to cope, you'll find that you need to hack the standard libraries to implement periodic reload to get the right information. Once you do, you have the issues described above for new information. Many things right now in the kernel depend on UTC being right very early. If you delay that, then other things will be wrong. Any filesystem that has to store dates in UTC won't be able to update them until you know what UTC is. This can cause sequencing issue if you have to write any files before you get this knowledge. Sure, you can do a half-assed job of papering over these problems, but they are the problems you'll have if you go the TAI route. The problem is so much more than just display. And unless it just works by default, there will be problems. In the past the answer has been 'well, special needs people need to go to extra lengths' which has been a huge cop-out. They already do, and the challenges of implementation and logistics can be extensive. > If you insist that file times should be UTC then the kernel could > convert the TAI time stamps to UTC before writing the file time stamps. Only if it has perfect knowledge of all leap seconds ever. Otherwise you make > For example, ntpd already passes the TAI offset down to the kernel if it > knows this number, e.g. from a leap second file, or via autokey from an > NTP server. that helps, but it's only the first step on a long journey. Warner _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
