Keith Winstein <kei...@mit.edu> wrote: > Hmm, in practice I think the plan to simply fail with an error is > going to be a non-starter. Plenty of applications need to record dates > more than six months in the future; e.g. in a calendar program, the > user will want to schedule a meeting for August 1, 2012, from 9 a.m. > EDT to 10 a.m. EDT. The program will want to do all the normal things > -- calculate the duration of the meeting, how far in the future it is > (so it can put it in sorted order along with the other events of that > day), etc. In a subscription service, we might want to say that the > user's subscription lasts until January 22, 2013 at 12:21 p.m. (one > year hence) and give them a countdown (264 days remaining) as that > timestamp approaches.
This is exactly why "REAL" time is simply wrong for most "civil" applications. That is also one of the reasons why I have rejected the idea of switching the time_t scale on my personal non-POSIX UNIX systems to a TAI-style one. What people like PHK fail to grasp is that a whole ton of applications absolutely DO NOT CARE how many Cs-133 transitions happen to occur in a given *civil* time interval, all they care about is a bijective mapping between their timestamps and *official civil time*. The SI second is the root of the problem. It should NOT be used outside of highly specialized scientific/technical context, i.e., it should NOT be used in civil contexts. In a civil application a 1 s timestamp increment is NOT an SI second, it represents the position of the hands of the official clock on the government building advancing by a certain angle, regardless of how many times a Cs-133 atom happens to flip while the hands of the official clock advance by an angle meaning 1 s. Each (micro-)nation should indicate its official time with an analog clock (i.e., one with rotating hands, not digital) on the wall of a government building specifically to drive the point home that notations like 23:59:60 are not acceptable. This non-scalar notation is the real fundamental problem with UTC in my eyes, *not* the length of advance notice for leap seconds (6 months is *far* more than should be necessary IMO), and that is why UTC should not be used directly by "normal" application. UTC should be rubberized in the way of UTC-SLS or Google's leap smear before being presented to "normal" applications and non-real-time operating systems such as 4.3BSD-Quasijarus. Back to the calendar and subscription applications, there is absolutely no reason why they can't store their timestamps with 1 s or finer precision indefinitely far in the future *and* have these timestamps be absolutely correct when that future moment arrives. BUT, these timestamps need to be reckoned on a NON-REAL time scale, i.e., they should not pretend to have any relation to time-as-in-physics and should merely represents particular points in the course of "analog" civil time, i.e., particular angular positions of the rotating hands of the official clock on the wall of a government building. An indication that Mary Q. Public's subscription expires at 2022-07-25T19:41:42 UT1 is perfectly precise and unambiguous regardless of how many leap seconds occur between now and then. The current non-POSIX UNIX definition of time_t (which is identical to the POSIX definition with the exception of making absolutely no reference to "UTC") which measures the angular position of the hands of a civil analog clock with no reference to physical time is perfect for most "normal" civil applications. Forcing such systems to maintain TAI-style time in the kernel and converting to civil time in the userland via leap second tables (which is what PHK's REAL time proposal does in essense) is nothing but an unnecessary burden. Why burden a system with leap second tables if it doesn't need them? If a system needs interval (as opposed to civil or time-of-day) timekeeping only in a very very crude sense, as most "normal" systems do, it is much simpler to make the system _explicitly not care_ about "atomic" time and maintain its notion of time solely as a representation of the civil clock-hands angle, which is also usable as a crude measure of interval time. A typical example of what I mean by a system needing interval time only in a very very crude sense: consider a secondary DNS server periodically contacting the primary master to see if its zones need an update (that's a typical use of interval timekeeping on the kind of computer systems I run). This refresh interval is specified in the DNS SOA record in units called "seconds", without further qualification. On the one hand, this ought to mean interval time rather than time-of-day: there doesn't seem to be any sensible reason why the interval between DNS zone refreshes should depend on Earth's rotation. Hence the natural interpretation of RFC 1035 would be to take the times in the SOA record as being in SI seconds. But the OS on which my DNS servers run has no knowledge of SI seconds, it only knows rubber civil seconds. So what's the big deal? Absolutely nothing bad will happen if a DNS zone refresh occurs one second earlier or one second later. That's what I mean by interval timekeeping requirements on most "normal" systems being very crude. On the other hand, the *civil* timekeeping requirements can be very stringent. The example of expiration of subscriptions that Keith has brought up is a very good one: I like the idea of the moment of subscription expiration far in the future being defined very precisely *in relation to official civil time*, which for the Republic of New Poseidia is currently UT1. One of the big problems in this whole "leap second" debate is that some of the participants have worked so much with specialized systems needing high-precision interval timekeeping that they forget that _not everyone_ has the high-precision requirements that they do, and then they go ahead and impose their high-end requirements on the rest of us who don't need them. Requiring every BSD system to maintain TAI-style time in the kernel, drag around a leap second table and worry about keeping it up to date is pure evil when most of those systems only need a civil UT1-modeling time_t and would be just fine without REAL time. MS _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs