Warner Losh <[email protected]> wrote: > Second, you are breaking one of the aspects of time
Wrong - I simply assert other people's right to define the word "time" in a different way than you do. There exist perfectly valid definitions of the word "time" which are distinct from "interval time", and which are not broken in any slightest way by my approach. > that is important for some application (you introduce a frequency error). No, I do not introduce any "frequency error" - I can't, because the term "frequency" has no defined meaning for the entity called "civil time". Instead, *you* introduce that error when and if you *misuse* what I provide as "civil time" as if it were "interval time", ignoring the product label that reads "don't do that". You are seeking to suppress Earth-based civil time because some people have misused and continue to misuse it in applications for which it is not appropriate. Are you also going to ban gasoline, because some people misuse it for the purpose of committing arson, even though the instructions on the gas pumps clearly say "for use as motor fuel only"? > This is no different than repeating a second There is one fundamental difference which you ignore: the mapping between UTR (equivalent to UTC-SLS or Google's leap smear) and TAI timestamps is 1-to-1, invertible, and precisely defined, when both are treated as real numbers of conceptually infinite precision. The reason why this bijective mapping is such a big deal is because (if people on your side of the fence were willing to open their eyes a little, that is) it would allow your precision real-time applications to work properly. Your whole beef with leap seconds seems to revolve around the notion that you have applications for which uniform "atomic" time is very important, which *also* need to interface with civil time (otherwise you could just use something like GPS time and ignore UTC altogether), and where no errors at all are tolerable, i.e., every timestamp must be exactly precise, no fudge factor whatsoever. Well, guess what, my system would allow you to have your cake and eat it, if you would only look at it with an open mind instead of shooting it down with prejudice! The *only* work required on your part would be to exercise a little care when defining your data structures: any place where you have a timestamp of any kind, be clear on whether it is a TAI-style one or a civil time one. Different data types would help: time_t is already well-established as the civil time data type, so use/invent a new one for TAI-style timestamps, like that realtime_t proposed by your buddy PHK on this list a couple of years ago. Any time you need to convert from one to the other, call a library function: the conversion is precisely defined and invertible. Run your internal clock on "atomic" time, and synthesize the "rubbery" civil time inside your system per the standard defined formula and the official Earth Corrections data table that goes with it. Problem solved! > But multiple time scales generally ends badly, Not necessarily - you still have not provided any valid objection to my design in which the "rubbery" time scale is algorithmically derived from the "atomic" one, and in which one can convert timestamps back and forth in an invertible manner. > or you eventually need to know the total number of leap seconds to translate > from your special time scale to UTC. Did you perhaps mean "to translate from UTR/UTC-SLS/LeapSmear to a TAI-like timescale"? Translating from a rubbery Earth-following timescale to UTC as the latter is currently defined requires no knowledge of the historical leap seconds. But yes, of course a high-precision "both real-time and civil" application of the kind you are presumably concerned with will need to be fed with up-to-date information regarding upcoming Earth Corrections, and to remember all historical ones. But where is the problem with that? Just define a standard data format, a standard protocol for transferring the updates, and a standard way of locating the authoritative servers - yes, will take some work, but certainly very doable. No more difficult than DNS. > So I'm happy that you found a solution for your problems, No, neither I nor anyone else in my shoes has yet found any solution to our biggest problem: namely, the threat that the familiar and working Earth-following UTC which we currently rely on as an acceptable realization of GMT will be forcibly taken away from us. If your camp has your way in the ITU next year, who is going to pay the cost of building a replacement for the lost UTC for those who require a good faith realization of GMT? What I need is an apparatus, such as a special-purpose Stratum 1 NTP server that serves out UTR instead of UTC, and which I can use to set the system time on all computer systems under my care. I will also need an easy way for my family members and friends to switch all of their time-keeping devices (computers, smartphones etc) from UTC to UTR, e.g., by pointing them to my special NTP server and finding some way to ensure that they can never use an "official UTC" server instead. Oh, and add the cost of going through the entire source for, say, a complex GNU/Linux distribution like Ubuntu, finding all instances of "UTC" and changing them to "GMT". *Big* cost. Who is going to pay for all of that? Or rather, whom should I sue to recover this cost I'm going to incur if your camp has your way? VLR, SF _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
