John Hawkinson <jh...@mit.edu> wrote: > Suppose a user enters an event in my calendar for 3:00pm US/Eastern on > August 1, 2014. > > Then a leap second happens. > > If my calendar software changes my event to start at 2:59:59pm
Scenarios like the above are precisely the reason why I, Markus Kuhn and Google Leap Smear users have been telling you all along that is wrong to use Newtonian/Einsteinian time when the real need is for *civil* time instead. We need two entirely separate and mostly-disconnected (see below) forms of time: N/E interval time on one hand, and "rubbery" civil time on the other hand. The problem is in the minds of people like PHK and Warner Losh. Every time we (me, Markus Kuhn and others of similar mind) advocate for a "rubbery" civil time scale with "rubber seconds", we get shot down with cries of how one can't use rubber time for air traffic control, etc. So what you, the "anti-rubber" crowd, are effectively saying is that "rubbery" civil time is not an acceptable substitute for uniform interval time. But we assert the converse as well: uniform interval time is not an acceptable substitute for rubbery civil time either, at least for those of us who (for whatever legal, moral, philosophical, religious or purely personal reasons) wish to retain Earth's rotation as the fundamental basis of *our* civil time. If inviduals like PHK and Warner Losh were stripped of their ill-gotten power to dictate to the rest of the software world their edict of "thou shalt use uniform interval time whether it's the appropriate timescale for you or not", then all "leap second problems" would instantly go away: *civil* time (as opposed to real time) applications would switch to using something like UTC-SLS or UTR (the former is contingent of UTC retaining its current leap seconds, but the latter is a variant without such requirement), whose "second" counts are NOT SI seconds, but merely measures of the angle by which the hands of an official civil time clock are turning, and all simple date-time math will work without burdening all of us with keeping track of leap seconds. Back to my point about uniform interval time and "rubbery" civil time being "mostly-disconnected": what I have in mind is a system like house electrical wiring with separate "ground" and "neutral" wires. At least here in USA, the electrical codes stipulate that the two be connected at one common point, but are then wired separately from that point onward. "Rubbery" civil time would be algorithmically derived from uniform interval time (atomic time), via a very simple linear formula like Markus Kuhn's UTC-SLS (my proposed UTR is essentially the same thing, but defined in a way that permits it to continue being maintained independently if UTC-as-we-know-it goes away), and ideally this algorithmic derivation of "rubbery civil time" from atomic time would be done at an authoritative source such as a national time lab - corresponding to the bonding point of "ground" and "neutral" wires in my electrical analogy. Continuing the electrical analogy, once a national time lab (it may have to be the national time lab of a small micronation like Sealand if no larger nation has the guts to step forward) has produced both forms of time (pure atomic time and a rubberized civil time, related by a known formula), both should be disseminated in parallel: for example, on different UDP port numbers of an NTP-like Internet time server. All users would then have ready access to both forms of time, but unlike in PHK-nian/Warner-Losh-ian world, no person, system or application would be involuntarily forced to use or care about a form of time they don't need. An application that needs interval time only (some "deeply embedded" technical system with no user interface at all which doesn't need to know or care what day or time it is in the human world) will be able to completely ignore the existence of the rubbery civil time, whereas an application that needs civil time only, like the OP's Excel example, would only look at the rubber second count and ignore the SI second count. Sure, there will be plenty of applications which need both, but once again, no problem. Air traffic control is a perfect example: use interval time internally for everything, but when displaying flight arrival and departure times for waiting passengers, convert them to the "rubbery" civil time for display, using the known formula and the widely-disseminated data table driving the rubberizations. VLR, SF _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs