Re: [LEAPSECS] Regarding the ITU's very immodest proposal
Rob Seaman <[EMAIL PROTECTED]> wrote: > Over all that time, it has been unclear exactly what entities are > pushing the inane initiative to eliminate leap seconds. So, when I > say "ITU", it is indeed eminently true that I'm implicating a drab > body of unimaginative technocrats, but I simply don't know who better > to address. And this tale doesn't depend on it. I think I know who they are. They are the PHKs of this world. There are plenty of people in our world who believe that their computers are more important than the planet we live on. Although we don't know exactly who are the people behind WP7A, I think our own PHK is a perfectly good example of what those people are like. "Mean solar time be damned, my computers don't care if the Sun is up or not!" The invisible entities behind WP7A probably have more political clout than our own dear PHK, but that's probably the only difference. If my hypothesis is correct in that the ITU people are like PHK, it would follow that you and Steve are wasting your breath trying to reason or plead with them. PHK has already told you that he is deaf to your pleas for mean solar time, he'll walk right over you because his systems outnumber yours 10 to 1. The same would go for the ITU WP7A gang if their mindset is the same as PHK's, as my hypothesis argues. If this is the case, I think that those of us who care about mean solar time need to take a totally different approach. Stop wasting our breath pleading to those who have already damned us, and commit civil disobedience instead. Forget about UTC and cut our losses. Go back to the old way we've used before UTC was invented. Commit civil disobedience by disregarding ITU orders and their leapless "UTC" radio broadcasts, and set your wristwatch, your wall clock, the clocks on your stove, microwave, PC and cellphone from your backyard analemmatic sundial instead. Run your own personal life on mean solar time in direct defiance to the orders of the time lords. This is what I am personally prepared to do. Who else is with me? I also wonder what will Monsieur Gambis do when push comes to shove... When the day comes when ITU orders him to stop sending out Bulletin C, will he have the courage to defy the bastards and continue sending leap second announcements from his home PC during off-work hours? If they don't allow him to use mailing lists hosted at obspm.fr for this purpose, there will be a long lineup of private citizens offering the use of their mailing list servers - I'll be the first to offer mine! Goddess Bless, MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Regarding the ITU's very immodest proposal
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > But exactly because I'm totally agnostic on solar time, the obvious > follow up question is: why leap seconds at all ? Well, I actually prefer rubber seconds, but I can live with leap seconds too, I just turn them into rubber seconds myself. I use continuous real-number-expressible rubber time on my adamantly non-POSIX UNIX systems (4.3BSD-Quasijarus). > People live up to 5 hours away from solar time already today, so > it cannot be very important to have the sun in south at noon. I am not one of those people and never will be. In fact I feel strongly enough about natural mean solar time that I refuse to obey DST. In less than a month everyone around me is going to move their clocks one hour forward, I will not. I commit civil disobedience for the greater part of every year by running my personal life on natural time instead of DST. Since I already commit civil disobedience by a whole hour for the greater part of every year, it would only be a little extra difference (another few seconds) when UTC is eviscerated and I have to start generating my own rubber time scale anchored to mean solar time. And yes, it is a religious matter to me. > We would have to maintain earth rotatation angle as a scientic > exercise, along with all the other earth rotation parameters. Good, this information will be very useful to me for generating my civil disobedience time scale. And yes, I will make my rebel time scale available to the rest of the world via an NTP-like protocol on a different port number. I hope Hugo Chavez likes it. > We can leave any necessary adjustments to civil time, if/when night > turns into day, to the national governments who already are far too > keen to fiddle timezones for their own economic welfare. And some of us who do not trust those national governments imposed on us against our will shall take the matters into our own hands. > Downside ? People with thing pointing to extraterrestial objects > are going to be cross, but they'll get over it. People with things pointing to ET objects are not the only ones, spiritual people are the other group. I don't have any thing pointing to any object, but I still care. And no, we (the spiritual group, dunno about the astronomers) will NOT get over it, we shall commit civil disobedience instead. > Nothing of any technical nature has any influence on the proposals > chances of getting ratified in ITU, that's purely a matter of > politics, most of it under the radar at civil servant level, and > once the plenum vote approaches, also at ambasador level if USA > feels badly enough for this. Somehow I doubt that *every* nation will comply with this edict. I can just see Venezuela and the Muslim nations saying "no way in hell" and running on their own mean solar time while USA and other "first world" nations run on the eviscerated UTC. Fun times ahead! Note to self: make friends with Hugo Chavez and convince him to adopt my rubber time scale. Goddess Bless, MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] How good could civil timekeeping be?
Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > This is the point where the POSIX people shot us in the feet by > ignoring leap-seconds. Why care about POSIX at all? Why not use a non-POSIX UNIX system then? > The time_t type, contains the number of SI seconds since 1970-01-01 > 00:00:00 UTC *ignoring all leapseconds*. Dunno about POSIX, but in UNIX-in-4-capitals which predates POSIX, time_t does NOT mean what you say. UNIX as opposed to POSIX time_t measures the angle by which the hands of a wall clock have rotated since since they displayed midnight 1970-01-01 in Greenwich. It is a wall clock rotation angle and has absolutely nothing to do with SI seconds or physical time interval. > And down at a hairsbreadth, you cannot by looking at a time_t value, > tell the leap second from the second right before it. (In some > cases it's the second after, but that's clearly a bug since the > leap second is the last second in the preceeding 24 hour UTC period.) Rubber seconds solve this problem. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Schedule for success
Tony Finch wrote: > Should we switch to the French Revolutionary Calendar to prevent > Christmas drifting away further and faster from the winter solstice? Yes, absolutely! Or even better, the Republic of Terra Calendar: http://ivan.Harhan.ORG/RT/Calendar/spec.txt MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Schedule for success
John Hein wrote: > By the way, that's a lower case 'c' in 'calendar'. Yes, thank you for catching my mistake; the correct URL is: http://ivan.Harhan.ORG/RT/calendar/spec.txt It was a human mistake on my part, I had typed the URL in from memory without checking it. > Let me guess, you > use outlook or something similarly helpful. Oh no, absolutely not, Microsuxx software (both OSes and apps) is totally banned at this facility. I use the UNIX Mail program on 4.3BSD-Quasijarus, which is just one notch above whisting into a phone to create modem tones corresponding to 0s and 1s in terms of software sophistication. And by the way, this adamantly non-POSIX UNIX system uses rubber seconds! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Cheating means more planning, not less
Rob Seaman wrote: > However, nobody has been arguing for rubber seconds. I have consistently been arguing for rubber seconds! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Cheating means more planning, not less
M. Warner Losh wrote: > I know that nobody is proposing rubber seconds today. Wrong! I am! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Cheating means more planning, not less
M. Warner Losh wrote: > I don't think that's a viable thing to do. It would play havoc with > anything except the most low-precision timing applications. But civil time *is* a low-precision timing application! > And if > you don't solve the problem for high-precision timing applications, > I'm not sure that it is a viable solution. Those need to use a diffirent time scale decoupled from civil time, i.e., TAI, GPS, TT, whatever. There need to be two different seconds, a civil second and a scientific second. The latter would be better renamed to essen. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Schedule for success
Poul-Henning Kamp wrote: > Time-lords make a point about it nontheless: whenever somebody talks > about using TAI for something, they state in no uncertain terms that > this is not to be done. Then let's just call it TAPF for Temps Atomique Pedant-Free. TAPF is identical with TAI in all ways but one single exception: when the pedants say "you can't use TAI", that doesn't apply to TAPF because the latter is pedant-free! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Leap Quirks
Hello all, This discussion about the meaning of UNIX and POSIX time_t in terms of UTC/TAI/whatnot that has just moved here from the time-nuts list has pushed some of my religious hot buttons, so I feel the rhetorical imperative to state my position. But first a disclaimer: I absolutely do not care about POSIX because it is a standard which I refuse to bow down to. I only care about UNIX, the operating system that predates POSIX by at least a decade and a half. I use Ancient UNIX systems which predate POSIX and will never-ever-ever convert, so everything I say about UNIX time_t specifically applies to non-POSIX, pre-POSIX and POSIX-defying UNIX systems, not to anything POSIX-compliant. Examples of systems I'm talking about are UNIX Version 7 from 1979, UC Berkeley's 4.3BSD from 1986 and my own 4.3BSD-Quasijarus from which I send this E-mail in the present. All that talk about whether UNIX time_t is supposed to track UTC or TAI or whatever is totally wrong. It has nothing to do with any kind of precision timekeeping whatsoever, nor even with time itself in the strict definition of that term. Instead it is defined as a rotation angle of a wall clock. One good way to define Classic UNIX time_t would be "the number of second marks by which the hands of a civil time clock in Phoenix, Arizona have rotated since they displayed 1969-12-31T17:00:00". (Or replace Phoenix, Arizona with any other civil jurisdiction that is free of DST and adjust the time zone offset accordingly.) The point is, it has everything to do with clocks in the non-precision civil sense and nothing to do with time as seen by physicists and metrologists. Once again, UNIX time_t measures the rotation of clock hands on some city tower in Phoenix, Arizona, *not* time. If the hands of a wall clock turn too slow or too fast relative to precision time, time_t speeds up and slows down accordingly. Angle, not time! And while we are at it, in my definition a clock has absolutely nothing to do with time. A clock is a *civil* device (not a metrological one) that tells people when to get up, when to go to bed, when to expect meetings, phone calls, etc. and when to catch a bus to go to work or school. It has *absolutely nothing* to do with time as defined by physicists. (To be fair, it has nothing to do with Earth orientation either, but the latter is a convenient reference to set clocks to in the absence of a trusted higher civilisation.) Of course those of you who choose to obey POSIX or whatever will probably define time_t in some different way that takes precision timekeeping into account and thus has some connection to time scales such as UTC/TAI/whatever, but please realize that there are still non-POSIX UNIX systems in the world and whenever you receive any kind of communication over any network protocol from a non-POSIX UNIX system under my control that contains a time_t value, that value will measure the rotation angle of a clock in Phoenix, AZ, *NOT* time of any kind. Nothing whatsoever to do with SI seconds or UTC or TAI, the units of my time_t are tick marks on the round face of a Big Ben-style clock, not SI seconds. (Unfortunately Big Ben itself doesn't qualify because they probably muck with it for DST; same story with the Kremlin tower clock in Moscow. Hence we need a civil clock of similar stature in a place like Arizona where there's no DST abomination.) MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Leap Quirks
M. Warner Losh wrote: > Almost all the posix mistakes are > relegated to tty handling :). That's another major reason why I hate POSIX. I will never adopt termios and I'm very proud to have the original sgtty in 4.3BSD-Quasijarus instead! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Leap Quirks
M. Warner Losh wrote: > Is that an adjusted or unadjusted clock? :) Adjusted for what? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [time-nuts] Leap Quirks
Rob Seaman wrote: > If you're looking for an Arizona-based standard, surely Sedona is the > benchmark :-) > > http://www.lovesedona.com/01.htm Yup, been there once for a UFO/spiritual conference. Very beautiful indeed. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1
Tony Finch wrote: > No. You do not run any systems synced to solar GMT. No-one does. I very soon will, as soon as I get my rubber time generator working. MS, who wants to live his life on rubber time (rubber seconds). ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1
Tony Finch wrote: > Oh, do tell, where will you get your GMT reference from? If I have trouble figuring it out myself, I'll just E-mail Rob Seaman and ask him what time it is. Given that his views on the subject as expressed on this list are much closer to mine than, say, PHK's, I would trust his answer better than ITU's. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] h2g2
p...@2038bug.com wrote: > > Nobody cares here that solar time and civil time > > are 43 minutes off. > > *I* care I do too! > but I'm not important - I'm just one person There are TWO of us now! > many people might care and many people are not getting to make > the decision because the decision is being made for them. That is why I am making preparations for generating my own synthetic time scale that is steered to serve a realization of MST, contingency plans for the day when we may no longer be able to depend on Daniel Gambis to do it for us. I really liked your earlier idea of setting up an NTP server that would serve a smooth, variable-rate timescale like UT1 or UTS or UTC-SLS, and have an associated pledge to continue serving this form of Earth-following time regardless of what the ITU does to UTC. I am thinking along very similar lines myself. > further, it's not a decision we can *ever* go back on once it is > made because reversing back to solar to time would be politically > far too difficult to get collaboration on. But as long as you and I continue to operate our own law-defiant NTP servers which serve our realization of Earth time instead of the s**t that ITU peddles, those nature-loving people who wish to live their personal lives on mean solar time can simply choose to point their own ntpd instances at our servers instead of those following the ITU - problem solved. Furthermore, there are still quite a few countries left on Earth whose system of rulership is very non-Western. Perhaps we can convince Raul Castro or Hugo Chavez to use MST instead of ITU time as the basis of legal time in Cuba or Venezuela, and to take their time reference from our "rebel" NTP servers? Or perhaps we can team with the folks in the Arab world who are working on the Mecca Time idea? I would be very willing to work with *anyone* who is in favor of Earth-anchored time. > that some NASA/ITU/whoever people find leap seconds "inconvenient" > for programmers is NOT sufficient reason to ever have started > pursuing this agenda. Total agreement! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 45, Issue 1
Ian Batten wrote: > I have a dim memory, based on wrestling with one of the *BSD's NTP > implementation in the mid 1990s, that one Unix decided to tick TAI > rather than UTC and move leap-seconds into userspace. But it's all > very dim... Olson's tz implementation did that at an early point in its history. Timeline of its adoption in BSD-land: * 4.3BSD-Tahoe had one of the earliest versions of the tz library which did not concern itself with such things. (I.e., it still ran on a vague "GMT" rather than anything more precisely defined like UTC or TAI.) That's what my current 4.3BSD-Quasijarus systems have, although I don't really use the tz part of it: I always run everything with "localtime" set to GMT (like in the headers of this E-mail). * By 4.4BSD time the Olson library had developed the infamous "posix" and "right" files. 4.4BSD shipped with the "right" config by default, so indeed it attempted to run the kernel on TAI and do the leap seconds in userland. The problem with that approach is that if the user/sysadmin never updates the leap second table (e.g., ignorant of its existence) and sets the system time from a wall clock via the date command, the resutling kernel time will be something in between TAI and UTC, more like UTC shifted by some constant offset corresponding to the # of leap seconds at the time of the OS release. * From what I understand the 4.4BSD-derived BSD systems have switched to using the "posix" versions of the Olson tz files. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coming of age in the solar system
M. Warner Losh wrote: > Except on leap second day, when the sexagesimalliness breaks with an > irregular radix. Yup, that's why I seriously dislike leap seconds and prefer rubber seconds instead. (By the latter I mean something like Marcus Kuhn's UTS aka UTC-SLS.) > In effect, the proposal to stop inserting leap > seconds restores this invariant that goes back to the Sumerians by > eliminating the irregular radix :) Except that the cure (disconnecting the concept of a day from the sunrise/sunset cycle) is worse than the disease (the leap second silliness). Rubber seconds a la UTS/UTC-SLS eliminate the 23:59:60 insanity *without* killing mean solar time. But at least with the darned leap seconds my time_t disagrees with UTC "legal time" only during the short interval during which I make my time_t clock advance by 10 units over the course of 11 SI seconds; if ITU has their way, I and the world will set out on a course of ever- increasing time drift. (That is, at the present time I schedule a batch of 10 elongated seconds, each equal to 1.1 SI s in duration, at the same time when Daniel Gambis schedules a leap second. But I am fully prepared to do it on my own: when the evil ITU comes forward to take away Monsieur Gambis' authority to issue leap seconds, I will NOT bend over like a submissive and switch to living my life on a timescale that's decoupled from MST. Instead I will simply start scheduling elongated or perhaps shortened time_t seconds on my non-POSIX UNIX systems on my own, and still live my life on a timescale that is anchored to MST.) Goddess Bless, MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coming of age in the solar system
Tony Finch wrote:
> This reminds me of 2008-12-31 23:59:60 Z when a lot of Oracle systems
> crashed or rebooted because the Solaris clock went backwards.
That's Solaris' fault then. It wouldn't happen under 4.3BSD-Quasijarus,
because I don't allow the clock to go backward or to stop altogether, it
only adjusts its ticking rate by +/- 10% or so to discipline itself to
the external reference. Note the reference I'm using *can* do bad
things like stopping or going backward (that's what happens when I use
the present-day leaping UTC as the reference), but my ttsd (trivial time
synchronization daemon) is the only thing that has direct access to this
external reference, and it shields the rest of the system from its
badness.
My ttsd is as trivial as this (C pseudocode):
while (1) {
gettimeofday(&systime);
exttime = read_external_reference();
adjtime(exttime - systime);
sleep(3600);
// The duration of this ~1h sleep is measured by the system clock
// that's being slewed,
// but its exactness or inexactness is totally inconsequential.
}
Folks, this is ALL it takes to have a trouble-free internal time scale
in the presence of leap seconds!
MS
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coming of age in the solar system
Nero Imhard wrote: > I had already mentioned the Bernhardt precision sundial on this list. Its > precision is such that one or more adjustments would likely be necessary > during the lifetime of the sundial. So, given the sword of Damocles > hanging over UTC's head, I guess the smart thing to do now is to order > them with a scale designated UT instead of UTC or local time. ;-) Can we equip one of those precision sundials with some mechanism to read it automatically and electronically, so that we can use it as a time reference for an NTP server? You have hit the nail precisely on the head with "the sword of Damocles hanging over UTC's head". That is precisely the problem with UTC! It is not a question of whether or not the insipid ITU proposal succeeds or not this time around, the very fact that the Time Lords are even willing to seriously entertain the idea of such a dastardly act of deceit and dishonesty is what makes them totally untrustworthy in my eyes. They have already lost my trust, and that is why I want to switch to running my life on GMT rather than UTC or anything else that comes out of those bait-and-switch timekeepers. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Coming of age in the solar system
Paul Sheer wrote: > We can *never* go back once this bound grows. Never say never: if I came to power as a dictator in some 3rd world country, I would have absolutely no problem with issuing an edict to the entire population to adjust their clocks by, say, 30.4851122 seconds at a specified point in order to go back from ITU time to Mean Solar Time. I would make this restored MST my country's legal time, and vigorously enforce it. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] comments on DRR TF.460-6
Tony Finch wrote: > Are there any requirements for mean solar time other than astronomy and > celectial navigation? Yes: religion, philosophy and moral justice. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UTC Redefinition Advanced
Warner Losh wrote: > 2010 is a radically different world than 1970 when > leap seconds were invented. Then clearly the right solution is to abolish and ban all technology invented after December 31, 1979! MS P.S. This E-mail message has been composed and sent using 1979 technology. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Cost: getting rid of GMT & discontinuing leap seconds
Nero Imhard wrote: > leap seconds being a vast improvement over rubber seconds That is your opinion (and apparently that of the other technocrats), but I totally disagree. I want mean solar time, but I want it to be a real number with all the standard mathematical properties of a real number. Hence the time scale which I am building for my own personal use (and to be freely shared with any and all comrades who choose to join) in preparation for the day when the ITU pulls the rug from under us has rubber seconds. Goddess Bless, MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Saint Crispin's Day
Zefram wrote: > Time scales are not easily killed off. The general concept of a time > scale that uses leap seconds to coordinate TAI and UT obviously has > its advantages, and some users would presumably find it convenient to > continue to have such a time scale, even if they're no longer allowed > to call it "UTC". Suppose Alice R. Parks operates her own time scale with leap seconds in direct defiance to the ITU, aka civil disobedience. The ITU sends her threatening letters demanding that she not call it UTC, but she does call it UTC anyway. Are you saying you are going to vote for a sheriff who would storm her house with guns to force her to stop using the term UTC for her own time scale with her own leap seconds? > Would IERS be willing to continue as the canonical > arbiter of leap seconds? Or would some other de facto authority emerge? If Monsieur Gambis ceases to be employed by IERS, or if IERS reassigns him to a different job and prohibits him from using work computers to issue leap seconds, would he be willing to issue leap seconds from his home PC on his own personal time? It's only a few minutes of work two times a year, can't be that much of a burden. Monsieur Gambis, are you on this mailing list? Can you answer this question for us? Would you be willing to issue leap seconds on your own without any official authority employing you to do so? Oh, and our own beloved TVB whose time lab can keep UTC no worse than NIST or whoever owns the leapseconds.com domain. Once IERS ceases to allow the use of their IT resources to distribute leap second announcements, a new mailing list will need to be set up. Leapsecond.com is clearly a good place to host it - TVB, would you be willing? MS, who is ready to fight for mean solar time like a true revolutionary ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The good fight.
"Finkleman, Dave" wrote: > We are trying to do what several have suggested, prepare for what might > be inevitable. Naming ambiguity is a central issue. I'm going to call my timescale UTR. The 'R' stands for rebellious, revolutionary or rubber seconds. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] An example
Poul-Henning Kamp wrote: > I really think ATC systems are more important than some photographers > quest... Wrong! Ground all planes immediately! Outlaw air travel! Go back to stone age! Oh, and have PHK stoned to death for heresy while at it... MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Back to Basics
ashtongj wrote: > If I point a gun at the police when they show > up to assist the inspectors, the police will kill me. And what if your army is stronger than the police and you kill them, not the other way around? I have heard that the average ratio in USA is approximately 1000 citizens per pig (cop). So even if only 1% of us go out and shoot a pig, we still outnumber them 10 to 1! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
Paul Sheer wrote: > I have a strong suspician that if someone put a gun to your head and > said "Poul-Henning, we are not getting rid of leap seconds, but we are > telling YOU to make sure those computers don't crash next December" that > you would find that Poul-Henning suddenly started asking all the right > questions and having all sorts of brain waves. Hmm, I like that idea a lot. HUZZAH for putting a gun to PHK's head! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java: ThreeTen/JSR-310
Stephen Colebourne wrote: > If TAI claims a trademark or similar, then I will have to rename or > clarify. BIPM has not been consulted. The term I use is TAPF: Temps Atomique Pedant-Free. TAPF is officially defined by its defining authority (me) to be identical with TAI in every respect expect one: if any Time Lords tell you "thou shalt not use TAI", that prohibition does NOT extend to TAPF, hence you are free to continue using TAPF as you wish. In every other respect it is identical with TAI. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java: ThreeTen/JSR-310
Stephen Colebourne wrote: > Viewed from afar, leap seconds appear to be a really stupid idea. A > gross complication in the passage of time, that so few people care > about, yet can cause such nasty effects such as time going backwards. > > [...] > > The Earth does not rotate at 86400 SI seconds per day. Once I > internalised that fact properly, my requirements were clear. For the > main API days must have 86400 "seconds" (not necessarily SI) and days > were more important than seconds. > > [...] > > Given that, I needed a way for time to always move forwards, and to > resolve UTC to 86400. Solution UTC-SLS. > > Thus my conversion is based around the primary importance of the day, > and its subdivisions of hour, minute and second making a fixed 86400 > pattern. For the record, I agree with Stephen 100%. I choose to live my life on a rubber timescale similar to UTC-SLS, and I am prepared to use deadly firepower to defend my right to live my life on this timescale. If PHK or Warner Losh or their armed minions (aka local sheriffs enforcing laws made to follow ITU which is ideologically controlled by the likes of PHK and WL) come knocking on my door demanding that I give up my rubber seconds and switch to their "leapless UTC" or whatever, I will respond with gunfire. They'll probably kill me, but if I manage to kill at least one ITU UTC enforcement sheriff before I go down, my life will not have been lived in vain. IOW: the only way you will take my non-SI rubber seconds from me is from my cold dead hands. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java: ThreeTen/JSR-310
Warner Losh wrote: > Just for the record. I have no minions, armed or otherwise. Yes you do: they are called sheriffs/cops/etc, and are unfortunately present in almost every country on Earth with the possible exception of small countries like the Principality of Sealand which to my knowledge do not accept immigrants/refugees. And because the nation-state laws these cops/sheriffs/etc enforce include laws about "legal time" which are anchored to ITU's UTC which you and/or PHK influence through your support of the "murder the leap second" proposal, these armed goons of various nation-states ARE in effect your minions in this respect. You and/or PHK (I don't remember exactly which, I think PHK, but your positions are obviously similar) have said repeatedly on this list that using any time scale other than those tied to UTC through various "legal time" statutes is illegal in a criminal sense. Therefore, my refusal to use anything UTC-based and running my life on rubber time instead (I divide each *mean solar day* into exactly 86400 seconds of non-precision variable length) makes me a criminal, right? And I thus interpret your zealous support of ITU UTC timescale enforcement as a threat to sic your armed enforcers on me, and I am thus preparing to respond with gunfire in self-defense. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java: ThreeTen/JSR-310
Daniel R. Tobias wrote: > Is there actually anybody on any side of the great time scale debates > who advocates sending government agents to people's homes to ensure > that all their clocks are set to the "correct" standard, possibly > arresting my mom [...] Whether they mean it or not, that is effectively what PHK and his gang are advocating with their constant insistence on having local/national governments define what time it is. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
Stephen Colebourne wrote: > SI seconds are significant, but far less important than days. Yes, I love it when someone states the main point so concisely! That is exactly my main point as well, and I am delighted to know that there are now at least TWO of us on the planet who share this view! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Tinkering with stuff until it becomes too complex to understand
Daniel R. Tobias wrote: > the day was divided into 24 hours, of 60 minutes, of 60 seconds; any > kid can still easily learn that... Yup, so far, so good. > until the scientists had the > brilliant idea of redefining the second based on atomic clocks, > causing it to get unmoored from the sun and necessitate all the > complications this list talks about. THAT is clearly the mistake which needs to be reversed! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Consensus building?
Daniel R. Tobias wrote: > You could have multiple types of seconds, like you have troy and > avoirdupois ounces, and U.S. and imperial gallons. Yes, like I've been advocating all along. > NASA is already using a Martian second, based on subdividing the > solar day of Mars, that is a different length from the SI or Earth > rotation seconds. Yup, a perfect case in point. The size of NASA's team dealing with Mars exploration is considerably smaller than the Earth's population base that needs to use civil time, yet the PHK-style approach of keeping the second strictly SI and letting the day not matter didn't work even for the smart folks at NASA. If the mean solar day is important on Mars even though there are no humans there at the present moment (at least none that we know of officially), what makes you think that it could be dispensed away on Earth? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Consensus building?
Warner Losh wrote: > If I have 180 days to pay a loan, I have to pay it by a certain time, > UTC, on the 180th day or I'm in default. In this definition, the earth > enters into it only to the extent that UTC varies from 86400s days > during that interval. This might mean that it will be a little more or > a little less than 180 solar days. That's assuming that the loan agreement was signed in a jurisdiction that uses UTC as the basis of its legal time. But what if it was in a jurisdiction that uses mean solar time instead? I know, I know, you and PHK will argue that it may be MST on paper but UTC in practice, but if the stakes are high enough and some bad-ass lawyers get involved to pursue it through the courts, the outcome is far from certain. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Cutting our losses: MST without UTC
Hello leap second debaters, As I have stated here many times previously, I am utterly disgusted by what the ITU is considering doing to UTC. As I have also stated here many times previously, I will not sit back and allow the computer systems under my care to be at the mercy of whatever the ITU decides to do to UTC. For many years now I have been thinking about an actual implementable technical mechanism by way of which those who feel like I do can insulate themselves and their computer systems from the whim of the ITU by disconnecting from their UTC and using an alternate realisation of GMT. Well, I have finally written the first draft of the formal specification for this mechanism: http://ifctfvax.Harhan.ORG/timekeeping/draft-utrspec.txt http://ifctfvax.Harhan.ORG/timekeeping/draft-utrdef.txt Basically it is an alternate timescale in which the utrdef.txt file maintained and published by me takes the place of IERS Bulletin C. For as long as UTC leap seconds continue such that |DUT1| < 1 s, I will adjust UTR at exactly the same times when Daniel Gambis adjusts UTC, and the two timescales will remain in agreement. However, We the People reserve the right to steer UTR independent of UTC should the latter be deleteriously redefined. The latter part needs a little clarification. Even though the master copy of utrdef.txt resides on my server and I have the power to modify it in any way whatever, it would be utterly hypocritical of me to do it in the same unilateral manner in which the ITU is reigning over UTC. Instead the UTR specification linked to above (subclauses 4.3 and 4.4) calls for an open membership Internet mailing list to be created to which any person or entity with an interest in the UTR timescale (or for that manner any other realisation of GMT that is politically independent of ITU/UTC) is welcome to subscribe. That mailing list would be used to discuss: * Practical hardware and software implementations of UTR and other non-UTC timescales seeking to provide mean solar time; * Scheduling of future rubberization instances in UTR (which take the place of leap seconds); * Revisions to the UTR specification itself, which is currently only a draft for review. Particularly with respect to the last two points, my vision is to maintain the UTR timescale (in terms of scheduling rubberization instances in utrdef.txt and amending the spec itself) by consensus of the non-UTC mean solar time user community, rather than by unilateral edict. I know I am not the only person who is sickened and disgusted by what the ITU is doing to UTC. There have been occasional discussions on this mailing list in which others have suggested taking matters into our own hands and getting our own mean solar time in the event of UTC becoming unusable. If you are one of those people who would like to protest the deleterious redefinition of UTC by using a non-UTC realisation of GMT, I encourage you to read my draft UTR specification and the associated data file linked to above, and if you like the general idea, let's work together. I think we are going to need a new mailing list separate from this one. I feel that those of us who do need mean solar time should be able to discuss the practical and technical aspects of how we can get it in the absence of usable UTC without being constantly subjected to abuse and ridicule from those who argue that MST is rubbish, and I feel that trying to discuss it on this list would get us too much of the latter. Tom, how would you feel about setting up a new Mean Solar Time Users mailing list on leapsecond.com or leapsecond.org? I'm asking TVB rather than doing it myself for two reasons: 1. I don't have a good platform for hosting public mailing lists at the present moment; 2. Because I have stepped up to maintain UTR, having me own the mailing list as well would be a conflict of interest, or at least a perceived one. I would like the list to be open to discussions of *all* forms of non-UTC mean solar time, of which my UTR is only one possible realisation. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] MST Users: separate list or not?
Hello again, In my previous post announcing my first draft of the UTR timescale I have mentioned the possibility of there being a need for a new Mean Solar Time Users mailing list to be created. What I'm seeking here is input on whether that topic indeed warrants its own separate mailing list, or if it should be discussed on this list. As I understand it (someone please correct me if I'm wrong), the intended discussion topics for this list are: * Arguments for and against the merits of atomic time and mean solar time; * Arguments as to whether or not civil time should be tied to mean solar time; * Arguments as to which agency should have jurisdiction over which piece of the global timekeeping arrangement; * Arguments as to what the broadcast time scale should be like and what it should be called; * Arguments as to what should happen to UTC; * Arguments for and against the cessation of leap seconds in UTC: given that the ITU member-states will be voting on this one, I presume that the discussions/arguments are an attempt to sway those votes. OTOH, the MST Users mailing list would be a forum for those people who are faced with a non-negotiable requirement of using MST (regardless of whether that argument comes from technical considerations, philosophy or religion) to make and discuss non-UTC-based contingency plans in the event that the powers that be decide against us and UTC ceases to satisfy our requirements. So what's the opinion of other leapsecs members: a separate MST Users list, or part of this one? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] MST Users: separate list or not?
Poul-Henning Kamp wrote: > A separate list, where people who are interested can subscribe. Rob Seaman wrote: > I agree. OK, I accept this consensus then. However, I have a directed question to TVB, the owner of the leapsecond.com and leapsecond.org domains: do you think that the new Mean Solar Time Users list should be hosted under one of those domains, or not? Here's the reason I ask: Back in Oct 2010 there had been a thread on this list pondering the possibility that if IERS were to stop sending leap second announcements, someone else would pick up the tab. I had asked if TVB had considered the possibility that his leapsecond.com domain would be just perfect for that, and he replied: > I have leapsecond.org just waiting for that... So here's my question to TVB then: if you have already been considering the possibility of using one of your leapsecond domains to distribute unofficial / non-ITU / non-IERS leap second announcements, what about extending that to include *all* forms of non-ITU mean solar time, be they implemented via leaps, rubberization or foregoing all forms of precision timekeeping altogether and using only sundials? But thinking more about it, perhaps hosting the fully-generalized Mean Solar Time Users mailing list on a site that has "leapsecond" in its name would be sending the wrong message. We should emphasize Mean Solar Time as a fundamental requirement, not leap seconds as one possible implementation. Rob Seaman: > The suggested service on the other hand is a proposed solution to address > whatever ad hoc mix of use cases and their derived requirements. A trade-off > study would be needed to find out how it maps onto the civil timekeeping > requirements. But my intent for the MST Users list is to encourage discussion of *all* possible schemes for satisfying the requirement of using Mean Solar Time for civil timekeeping (which you agree *is* a requirement), not just my particular UTR scheme. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap smear
Ian Batten wrote: > So astronomers say. No-one else cares, Wrong! I care, and I'm not an astronomer. There have also been one or two other people on this mailing list who aren't astronomers, but who object to the redefinition of the day on purely philosophical grounds like I do. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What timekeeping system should the Terra Nova settlers use?
Daniel R. Tobias wrote: > How would the people on this list who advocate for various treatments > of future timekeeping in our own world deal with that situation? On > the one hand, it's of great importance to the settlers' lives that > they coordinate their time in some manner with the local solar time; > [...] > On the other hand, I expect they have a good deal of gadgetry and > scientific instruments which probably have dependencies on > frequencies and interval timing that are based firmly on the SI > second. So how would you reconcile this if you were the leader of > this colony? Exactly the same as my proposal for today's world: maintain two completely separate and independent kinds of time. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "China move could call time on GMT"
Poul-Henning Kamp wrote: > If and when they feel the need, I'm sure they will. > In 2600 AD, if I remember the prognosis ? For those countries/micronations who choose to maintain their legal time within 0.1 s of some good-faith form of Mean Solar Time, it will be much much sooner. Of course, the legal time in those countries probably isn't of concern for PHK as he wouldn't be advised to set foot on their soil: countries that feel like I do would most likely issue arrest warrants for him. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "China move could call time on GMT"
=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= wrote: > In all the discussions here, I still haven't seen any examples of things th= > at'll break that's not related to tracking things in the sky. LEGAL things would break. What the people like you fail to grok is that some of us are bound by *non-negotiable legal requirements* to live our lives on a time standard that's anchored to Mean Solar Time. The constitution of the new micronation I'm in the process of founding will have just such a requirement. If the ITU succeeds in its inane plan, it will immediately become illegal for me to use UTC for *anything*, and that would happen the instant their redefinition takes effect, i.e., has nothing to do with the magnitude of DUT1. Then I would have to *scramble* to build my own apparatus that can serve me with an alternate timescale that has no connection to UTC: it would be a massive project, taking my time away from other technical projects I'd like to work out, hence a very real cost. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] What is GMT?
Tony Finch wrote: > GMT was discontinued decades ago and has not had a coherent meaning for > even longer. For me "GMT" has a very simple meaning: it basically means "the exact timescale doesn't matter, it can be anything as long as it comes from someone like Rob Seaman and NOT from someone like PHK". UT1 would be perfectly fine, but so would UT2, UT0, UTC-SLS or just about any other version, OTHER THAN what PHK and the ITU are seeking. The system time on my non-POSIX UNIX systems is defined to be GMT, not UTC. Right now UTC disseminated via NTP (obtained from public Internet NTP servers) serves as an acceptable realization of GMT, but this will no longer be the case if the bastards in the ITU have their way this month. If the ITU bastards have their way, I'll be forced to drop all my other projects and *scramble* to build my own non-UTC GMT-generating apparatus before the first embargoed leap second occurs. The apparatus I have in mind is envisioned as being very similar to a typical stratum 1 NTP server (GPS in, Ethernet out), but with a special twist: instead of applying the "UTC offset" (or LS count or whatever it's called) transmitted by GPS, apply a different offset controlled by ME locally. I will then have to manually adjust this offset periodically to steer my timescale to the true GMT, i.e., to UT1 or whatever else happens to be convenient. And when this offset needs to change, it will be done via a rubberization process similar to UTC-SLS. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "China move could call time on GMT"
Tony Finch wrote: > Incorrect, because the civil calendar is tied to local solar time using > the time zone system. Local civil time is not going to move out of sync > with the sun, and therefore the calendar will also remain in sync. The problem with your argument is that the time zone system doesn't work for everyone. What is the "local civil time" for someone who doesn't hold citizenship in any country and lives on a boat that continuously circumnavigates the world? I choose to define the legal/civil time for my one-man micronation to be tied to some NATURAL phenomenon, something that is NOT subject to man's whim. Hence man-made UTC is not acceptable. Mean solar time is a natural phenomenon, so it's acceptable. I just have to pick some completely arbitrary longitude at which to measure this MST, and my own physical longitude at any given moment would be a poor choice because it changes all the time. Hence I've chosen the standard 0 deg longitude for obvious convenience. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What is GMT?
Warner Losh wrote: > There's a bit of an ambiguity in when that might be, since DUT1 drifts only > approximately 300ms every 6 months, there's often two or three choices for > dates for a leap second such that DUT1 still remains below 0.9s. Would you > try to resolve that at all, or just use whatever published DUT1 numbers to > reconstruct an approximation of UT1 and use that for your "GMT" base? I would proceed by building the apparatus first, then worrying about those things. The implementation I have in mind will be driven by the utrdef.txt file, and I've already posted a draft spec and an example utrdef.txt file a few months ago. My vision is that there will be a community of people who will have an unmet need for some form of Mean Solar Time once UTC ceases to fulfill this need as a result of deleterious redefinition. Someone needs to step up and create a Mean Solar Time Users mailing list to serve as a community gathering place for all people who are faced with a non-negotiable requirement for MST (be it legal, religious, philosophical or simply a personal choice) and who will need *some* way to continue satisfying this requirement in a post-UTC world. The MST Users mailing list needs to welcome *everyone* who has a need for MST regardless of the specific reason(s) why, and it needs to be open to *all* possible options for satisfying this requirement, be they leaps, rubberization or foregoing all precision timekeeping altogether and using only sundials. I would very much prefer for the MST Users mailing list to be created by someone other than me, but if no one else is willing, I'll bite the bullet and create it on one of my servers. Back to your original question, my preference would be to leave those decisions to the consensus of the MST Users community, but that requires creating the mailing list first. My vision is that questions like the one you've asked would be brought to the MST Users list for discussion, and once consensus is reached, I as the maintainer of the official utrdef.txt file used by the rubber duckies would merely encode the community consensus decision in the utrdef.txt file format. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What is GMT?
mike cook wrote: > I think an RFC for an NTP extension to support a rubbery time scale = > will be required so that all who wish to keep something approaching UT1 = > as civil time can do so. But are you sure that NTP would be the right protocol? The first and most immediate problem with NTP is that if the ITU bastards have their way this month, NTP over the public Internet will immediately become unreliable: some NTP servers will switch to the new ITU2012 timescale (my preferred unambiguous term for what will be deceptively called "UTC") while others will continue serving the existing UTC1972 timescale. As there would be no reliable way to tell which timescale is served from UDP port 123 at a given public server's IP address, NTP will cease to be a dependable protocol except when talking to servers which you administer yourself. So why bother with NTP at all then? The only reason in my mind to support NTP on the rubber duckie (in addition to the new protocol on a different UDP port specifically designed for disseminating UTR) is to force-feed UTR to existing closed-source NTP-expecting devices such as NAS (network-attached storage) appliances. These devices expect UTC via NTP from UDP port 123 on a server whose IP address you configure, but if you give it the IP address of a server you control yourself which serves UTR instead of UTC in packets which look no different from standard NTP, the target device will be forced to swallow it. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What is GMT?
Harlan Stenn wrote: > there are other issues afoot here, like > regardless of how one syncs time between machines, if one collects a > timestamp on a box, what timescale is that timestamp in? > > What about storing these timestamps? Displaying their values? > Comparing them with other timestamps from possibly different timescales? The answer is that chaos will ensue. That's what one gets for redefining existing timescales and forcing a totally different definition under an old name by bullying and fiat instead of cooperation and consensus. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "China move could call time on GMT"
Daniel R. Tobias wrote: > World time zone maps generally show a series of perfectly regular > time zones divided at the appropriate meridians through the oceans > wherever there aren't any nations that set their time otherwise for > political reasons. Yup, and these "ocean time zones" are defined apolitically as mean solar time at meridians of longitude equal to integral multiples of 15 degrees. Integral hour offsets from a redefined "UTC" would NOT be an acceptable realization of "civil time at sea" because they would correspond to MST not at the well-defined N*15 deg meridians, but at some other set of meridians wandering around the globe. > However, I suppose on any particular ship it would be up to the > captain to decide when to adjust ship time, not necessarily exactly > when those meridians are crossed. So I guess I should say that integral hour offsets from the ITU2012 form of "UTC" would not be an acceptable realization of "civil time at sea" on *my* ship. :-) Integral hour offsets from UTR generated by one of my rubber duckies would have to be used instead. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "China move could call time on GMT"
Nero Imhard wrote: > Fundamentally changing the semantics of a time scale while retaining the > name WILL be a future source of confusion. This can be prevented by > properly changing over legal time to a uniform time scale (which seems to > be the requirement). An essential feature of the honest approach you are proposing is that each sovereign nation will get to decide for itself whether or not it wants to switch over. Undoubtedly at least some nations will choose to stick with MST as the basis of their legal time. But that's exactly what the bastards apparently have their biggest problem with: their goal is to surreptitiously make *all* countries change the basis of their legal time without even knowing it! MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What is GMT?
Warner Losh wrote: > (1) NTP is defined by the RFC to be UTC today, Yes, but which version of UTC? Some NTP server operators may very well choose to continue serving a leaping version of UTC (what I call UTC1972) well past 2017, for a couple of reasons: a) because this "redefined UTC" is no longer a valid form of UT, some may very well regard the redefinition as illegitimate and continue using the old definition; b) the existing RFC said "UTC" when this term unambiguously meant a time scale with leap seconds, hence some may very well choose to interpret the RFC as specified a leaping timescale regardless of what someone else later does to the UTC acronym. And even if someone later writes a new RFC that explicitly specifies a leapless ITU2012 timescale, operators of existing NTP servers built to the old RFC could use the age of their existing equipment as casuistical justification for continuing to serve a leaping continuation of UTC1972 instead of ITU2012. Folks, the leaping version of UTC will NOT stop in 2017 no matter what the ITU may wish. If Monsier Gambis is unwilling to continue sending leap second bulletins from his home PC during non-work hours, I'm sure someone else will, and anyone who is enfused with a passionate love for leap seconds and a burning desire to continue using them will surely continue acting upon LS bulletins (and configuring his/her NTP servers to do so) whether they come from IERS or from somewhere else. > Why should this time be any different than the last time? Leap seconds > were rushed in, at the last minute with little coordination or cooperation > in a manner that left hard feelings for years. The difference is that with the vastly enlarged number of stakeholders, the protests can be a lot louder. The best protests are those done with actions rather than just words, and that means continuing to operate real-life systems according to the old definition, intentionally disregarding the illegitimate redefinition. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What is GMT?
I just wrote: : The difference is that with the vastly enlarged number of stakeholders, : the protests can be a lot louder. The best protests are those done : with actions rather than just words, and that means continuing to : operate real-life systems according to the old definition, : intentionally disregarding the illegitimate redefinition. I forgot to add: The budget barrier for entering the playing field is now much lower than it was in the early 1970s. Back when leap seconds were introduced, the only ones affected by the change were operators of time service radio stations. The latter are very expensive and manned by people whose position makes them very unlikely to want to engage in the kind of protests I'm calling for. But now things are different: the operator of every NTP server and every UNIX-like operating system is potentially affected, and these things are inexpensive enough to be in the hands of people who would very much like to be the new Rosa Parks. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Straw men
Ian Batten wrote: > > There are, for instance, ongoing Y2K-related issues. > [Citation Needed] I am continuing to deal with Y2K fallout issues in 4.3BSD-Quasijarus to the present day, as it becomes apparent to me that my initial fixes made just before the Y2K moment aren't good enough in the long term. The most recent code change I've made in connection with Y2K was just a few months ago in 2011-07: I have finally changed SCCS to use 4-digit years instead of just the last two digits. The change I had made earlier (just before the Y2K moment) maintained 2-digit years, but made it roll over cleanly from 99 to 00. Ditto in sendmail, troff and other places: I had kept 2-digit years almost everywhere and merely fixed things up so that 99 was followed by 00 rather than 100 or some other garbage. It was only years later that I slowly realized bit by bit that it was a poor solution and that the right thing to do was/is to move to full AD year numbers. If my memory serves me right, it was 2004 when I finally implemented the RFC 1123 change of mail header dates from 2-digit to 4-digit years, i.e., in early 2004 I was still sending mail with dates reading xx Jan 04 and such. The conversion to 4-digit years still isn't complete: 4.3BSD-Quasijarus troff and nroff still have my old 2-digit hack, such that \n(yr currently reads 12. > The set of equipment that needs any time other than civil time is > vanishingly small. It isn't just equipment that matters, it's also people. Every living person has an inalienable right to choose which timescale s/he wishes to use in his/her personal life. Many people have chosen to live their lives on mean solar time, and up to now have been relying on UTC to provide a low-cost readily accessible form of it. (Low cost meaning not having to operate one's own high-precision observatory and flywheel timekeeper, as each time station had to do in the pre-atomic days.) By fundamentally redefining the meaning of UTC (previous minor redefinitions were mere technical changes as to means of achieving the unchanged goal of serving something that can pass for MST, hence a red herring) without changing the name, you are attempting to force other people to change their personal timescales without them knowing it. That is called fraud and ought to be subject to criminal prosecution. > The question is, should the rest of us be obligated to use a time scale which > causes us difficulties which we could fix easily were it not for the needs of > a small scientific community? If you prefer a leapless atomic timescale for YOUR personal life, you have every right to it. But pick a new name for it: you have NO right to usurp the name "Universal Time" which others have already defined to be THEIR timescale, suited to their purposes rather than yours. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Straw men
Tony Finch wrote: > There should be no fragmentation of the underlying > timescale, and there will continue to be a consensus realization of it. How sure are you of the last part? How sure are you that some countries won't consider the ITU's UTC redefinition act to be fraudulent and illegitimate, and continue operating their national time services with leap seconds or some other mechanism (e.g., rubberization) that ties their national time base to MST? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Straw men
Ian Batten wrote: > Why would UTC be different between localities? Because different countries will react differently to the morally despicable and reprehensible actions of the ITU. Some countries will gleefully accept the redefined UTC as legitimate, while others will reject it as fraudulent. Hence different countries will have different UTCs: some with leaps, others without. If Daniel Gambis is unwilling to continue announcing leap seconds without sanction from the ITU, someone else will fill the void. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Straw men
Clive D.W. Feather wrote: > I don't need Universal Time, But I do. By what right are you seeking to take it away from me? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Straw men
Ian Batten wrote: > your watch is set to civil time; Because the word "you" and "your" when posted on a public mailing list effectively imply "everyone on the list", I can easy prove that your statement is false: *my* watch is set to whatever time *I* choose, which is *not* necessarily the same as "civil time". I live in an area where everyone around me observes DST, but I refuse to do DST, hence my personal time (displayed by all of my personal timepieces) differs from that of everyone around me by an hour for more than half of every year. > your computer and your PCR display civil time; Wrong again: my computer systems run on GMT and are configured to display only GMT (see the headers of this message for example), even though I'm an ocean and a continent away from Greenwich. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] "not my job" ?
Rob Seaman wrote: > Obviously we would be forced to adapt. We can't all be a "one-man > micronation" like Michael :-) More power to him, but that isn't a > "coordinated" plan either. My "one-man micronation" is connected to the Internet with its own public, static, world-reachable IPv4 address block and a few domains. My UTR time server will have a public, world-reachable IPv4 address (IPv6 connectively will probably be added soon too), and all of you will be more than welcome to get time from it. So it *is* a viable solution for more than just me. Furthermore, although my preference is to implement my UTR time server with custom PowerPC hardware rather than mere software hacks on a garden variety x86 box, I will publish all of my hardware schematics, PCB and gerber files etc (as in release all that into the public domain), so anyone else would be able to build his/her own UTR server identical to mine. I will also offer actual hardware units for the cost of what I have to pay for the PCBs, parts and assembly, i.e., zero profit margin for me. And if someone else finds a way to implement a functionally equivalent UTR server using only software instead of custom hardware, more power to them. As for my plan not being "coordinated", I beg to disagree as well. I have already posted a draft of the formal technical specification for the UTR timescale, which includes a mechanism for having all UTR users agree on exactly the same rubberizations. Brief summary: * An open-participation mailing list needs to be created on which all UTR users could gather, although I would prefer it to be a little more inclusive to *all* forms of Mean Solar Time in a post-UTC world, hence the proposed name MST Users. You, Rob, are personally invited to join, as are Michael Cook and Markus Kuhn. * The UTR specification does not stipulate any specific set of rubberizations, although for the sake of ease of implementation it requires the duration of each rubber second to be an integral number of SI milliseconds. But there are many possible rubberizations which would meet this constraint, and my vision is to have some community consensus rather than fiat drive that choice. Even if our Mean Solar Time Users mailing list has only 3 members initially (e.g., me, you and Michael Cook), our UTR timescale can be fully coordinated between the 3 of us. The official UTR timescale is defined by the utrdef.txt file, an ASCII text file whose format/syntax is defined by the UTR specification, but the consensus at to exactly when should rubberizations occur and what shape they should take should be reached on the mailing list first. My vision is that we would reach consensus on our mailing list, then the maintainer of the actual utrdef.txt on the official server would merely encode the consensus decision in the standard file format/syntax. All actual UTR time server implementations, whether it's my preferred PowerPC hardware implementation or someone else's functionally equivalent software implementation, would periodically poll the server holding the master copy of the official utrdef.txt, and automatically pull down any updates well advance of each rubberization. As a result all UTR users will independently regenerate exactly the same UTR time scale, with rubberizations occurring at exactly the same agreed-upon times, regardless of which actual hw/sw implementation they choose to use. No worse than the current UTC, i.e., no less coordinated. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ISO TC 37
Warner Losh wrote: > The ITU standard is the standard for radio broadcast time. That's why > everybody broadcasts UTC (+/- some fixed offset) today. To conform with > international standards, they would broadcast the new timescale. But how are you going to enforce it? Suppose "rogue" country X decides to operate, say, a 1 MW (megawatt) transmitter broadcasting a time code that deliberately disobeys the ITU-R recommendation. Furthermore, suppose that transmitter operates on a "squatted" frequency without asking anyone else for permission. The transmitter is physically located on the sovereign territory of country X, but its emissions can be easily heard well outside of that country. Are you (USA or whoever) saying you are going to drop atomic bombs on country X for doing this? > So the more pertinent question will be 'what are the labs going to do?' > since that's what everybody, or nearly everybody, will blindly follow. But not every country has its own time lab: some poorer countries (including most micronations) can't afford one. A country that can't afford its own time lab has to rely on the time broadcasts from other countries. However, such a country could choose to apply an offset to those foreign transmissions to get its legal time. Suppose that the time code transmitted by WWVx in USA, whatever its name, gets 1.5 s ahead of UT1. Let's say a hypothetical micronation located 14 nautical miles off the coast of USA chooses UT1 as the basis of its legal time, but can't afford its own time lab, so it has to rely on WWVx transmissions instead. The nation in question (micro or otherwise) could easily make a law that requires every user of WWVx transmissions to subtract 1.5 s from the time received from WWVx before using it in any legal context. Furthermore, if country X can afford its own time code transmitter but not its own time lab, it could set up equipment that receives foreign time codes, automatically applies an offset that is locally controlled to bring the time back into alignment with some form of MST, and retransmits it back out (maybe even at a megawatt or more on a squatted frequency) as "rubber time" that is directly usable as a realization of MST without the user having to apply any offsets. Or if a megawatt transmitter on a squatted frequency isn't an option, substitute a publicly reachable Internet server instead. > They are the domain experts, they deliver time to me, why would I > use anything else[*]? Religious/philosophical reasons. > Who wants to be the first lab that's the "odd man" out? The time community > is very tight knit and my sense is that peer pressure will keep everybody > doing the same thing. It is indeed rather unlikely that any of the already existing time labs would have the courage to act on a leap second notice sent from Daniel Gambis' personal Gmail account instead of the IERS servers, unfortunately. However, if some highly ideologically-driven nation that does not currently own a time lab ponies up the cash to set a new one up, it could very well be set up to deliver an atomic clock-based timescale that is steered into alignment with MST. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Steve Allen wrote: > > TAI can be derived from UTC, GPS and other broadcast timescales, so > > availability is fine. > > Indications have been that BIPM will disagree violently with that > statement. And what's wrong with simply ignoring them after telling them to STFU? MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Keith Winstein 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,
Re: [LEAPSECS] Lets get REAL about time.
Mark Calabretta wrote: > In the former, on reaching 60, the second hand would stay there for 2 > seconds thus making it impossible to track time during a leap second. > > In the latter, the second hand would move continuously past 60 to 01 > second and immediately flick back to 60, thus making it possible to > reckon time during a leap second. Both wrong. The right way is UTC-SLS. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tom Van Baak wrote: > Except it doesn't work for binary systems. 32.768 Hz watches > would prefer steps of 1/1024 s. UTS was a fine idea until it > was so overly specified. Since you are already dealing with > timekeepers that do not care so much about sub-second > accuracy a smoothed leap second proposal should allow > flexibility. I vigorously advocate only the general idea of rubberization. The exact mode of rubberization is up to each individual implementor in practice. Alice and Bob may choose two different rubberization schemes, but the magnitude of the difference between their clock readings can't exceed 1 s at any point. MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
Tony Finch wrote: > Have there really been that many? Any refs to ones other than Markus's and > Google's? There is also my UTR scheme: http://ifctfvax.Harhan.ORG/timekeeping/draft-utrspec.txt http://ifctfvax.Harhan.ORG/timekeeping/draft-utrdef.txt MS ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
