Hal Murray wrote: > > s...@ucolick.org said: >> This idea pushes extra complexity into every implementation of low level >> kernel-space software, firmware, and hardware. That's nice as a policy for >> full employment of programmers, but it's hard to justify by any other >> metric. Instead those low level places should be as simple as possible, and >> that means making the underlying precision time scale, and thus any >> broadcast distributions of a precision time scale, as simple as possible. > > Has anybody done any serious thinking about fixing the POSIX problem? > > I assume the first step would be to have the kernel keep time in a non > leaping time scale. Is UT1 the obvious choice?
Wouldn't that basically mean to get back rubber band seconds? Also, how would you distribute UT1? Via a table with a correction value to TAI? 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 tzdist protocol could be used to update both the TZ DB and the leap second table. This could solve the ambiguity of duplicate time stamps which you also have at the end of a DST interval, unless you know the DST status. I mean at least the conversion from TAI to UTC. The conversion from UTC back to TAI can only be unambiguous if you have some status information with the time stamp. For example, if you want to derive UTC from local time then you need to know the basic local time offset *and* the DST status. Otherwise you get ambiguous conversion results at least at the end of a DST period where 1 hour is repeated. This is similar with UTC. If the timestamp APIs always returned a timestamp+status you could deal with that unambiguously. However, implementation of the API would be expensive with regard to computation time since it has to make sure that the time stamp and status information are always returned consistently. This is bad for applications which want to read time stamps as fast as possible. > Would we need a version of ntp that used that time scale? (or some > non-leaping time scale) I think a compatible approach would be to let existing API calls behave like they do now, and provide new enhanced API calls where the application can determine if the kernel runs on TAI, and then use different calls to return a TAI time stamp only, or a raw UTC time stamp derived from TAI, or a time stamp plus status to resolve the ambiguity. For example, Meinberg PCI cards provide API calls which return a 64 bit time stamp very fast for applications which need it, and there are other API calls which return a UTC time stamp, plus local time offset, plus a status field indicating if the device is synchronized, if a leap second is pending, if the current time stamp is in the middle of a leap second, etc. Martin _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs