Re: [LEAPSECS] UTC fails
Steve, And UTC has failed miserably. POSIX says UTC has no leaps. Google says UTC has occasional days with stretches of seconds which are of varying lengths. De facto, there is no single UTC time scale. Right! And many more examples of UTC fails -- the RTC of any unix computer. Any windows computer. Arduino and the microcontroller world. GPS receivers displaying 59 twice or 00 twice. IRIG. FAT (memory cards). Excel. eBay. Analog clocks. It's getting increasingly awkward decade after decade to have all these holes in the practical implementation of UTC. Remember the paper that started all of this had time to change in the title: http://gauss.gge.unb.ca/papers.pdf/gpsworld.november99.pdf Remember also that in the 60's when leap seconds were conceived there were no personal computers, no quartz wrist watches, no internet, sailors used sextants or LORAN, WWV ticked on short-wave, teletypes were 110 baud, NASA used nixie tubes (no LED's), phones were black and rotary, you could dial in town with 4 digits, TV's had 3 channels, computers were the size of rooms and turned off at night, etc. Almost nobody knew about or was affected by leap seconds. It was a reasonable technical solution for the era. I think those that want to get rid of leap seconds have a point; it is too awkward a universal solution for the 21st century. But the bottom line for engineers who are implementing operational systems that depend on timing is much simpler. If you want to engage with a 15 year long international flame war where people cannot agree on elapsed time to within several seconds, then go ahead, choose the internationally-recommended UTC. But if you want to get something working that does not get bothered by differences of several nanoseconds, then ignore the international recommendations and choose GPS time, Galileo, BeiDou, the Indian satellite system time, or some PTP-based system via a device which claims to be using one of those to supply TAI. Good point. I agree. But its sad. And would have been unnecessary. This proliferation of timescales, even back in the late 90's, is the main reason (so I was told) that USNO proposed that leap seconds be re-considered. Dennis can provide more info if he's still on the list. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Letters Blogatory
Overall he seems to make a good philosophical argument why solar time is good for humans. But his conclusion seems confused. ... let the airlines and the Internet companies use TAI. Ah, the airlines already use GPS (TAI-like) for navigation, and local civil time for scheduling, while the internet companies grapple with TAI-like timescales, POSIX, and local civil time representations at machine and human levels. There's atomic time and solar time and thats the inconvenient truth that TAI v.s. UTC with Leap Seconds reconciles. That's the whole point. In other words, let them simply stop adjusting for for leap seconds. Let the atomic clocks become progressively more wrong. Whoa! Hold the phone! What do you mean? Adjust TAI's frequency to match Earth?!? Nobody anywhere is suggesting that! Of does he mean adjust the count or labeling of TAI? Nobody's suggesting that either. That's what UTC is. It seems to me we have our priorities backwards when we worry about how to keep our everyday natural time in sync with our atomic clocks instead of vice versa! Huh? I think he means the solar day ought to be the priority because its more meaningful for humans, which I generally agree with. But this is an argument to keep Leap Seconds, not change TAI. He seems to have missed the fact he himself makes earlier that there are two timescales. Articles like that add confusion to the public discussion. -Brooks On 2015-03-11 09:44 AM, Steve Allen wrote: Ted Folkman is a lawyer who blogs about international law https://lettersblogatory.com/2015/03/11/letters-blogatory-opposes-abolition-of-the-leap-second/#more-20126 -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bio cycles and dueling timescales (was Letters Blogatory)
You are correct to not call biological cycles clocks. Doing so is one of my pet peeves, and I've recently published an article castigating the psychophysics folks for doing so. The reference to that is: Birth, Kevin. 2014. Non-clocklike Features of Psychological Timing and Alternatives to the Clock Metaphor. Timing and Time Perception 2(3):312-324. The bats, being mammals, have a SCN that is entrained by light/dark cycles. The repetition in their daily cycles is due to the interaction of the SCN's two parts--the free-running part with a @24 period, and a photosensitive part that resets the free-running part daily. The relationship of these two parts allow the bats to anticipate evening twilight. Most likely there are hormonal rhythms that get them up and going that start to kick in a hour or so before twilight. The reason why they come out starting 7-9 minutes after sunset, despite seasonal variability in daylight, is that the dorsal portion of the SCN is reset each day (probably from a sunset cue), and then free-runs for @24 hours until it is reset the next day. The same sort of mechanism (although involving the pineal) is is also why roosters' crows anticipate the dawn (I also have an article on roosters if you are interested). With roosters I know that the hormone cycle that anticipates sunrise is a testosterone cycle. There is one study that I know about nuclear subs. Here is the reference: Kelly, TL et al. 1999. Nonentrained circadian rhythms of melatonin in sumbmariners scheduled to an 18-hour day. Journal of Biological Rhythms, 14: 190-196. The Martian day is probably within the range that some people could entrain to it--the bigger problem would probably be bureaucrats insisting that anyone on Mars live by a UTC day, which would have them feeling like they had jetlag within about a week. While I know several anthropologists who have worked in Antarctica, I don't know any chronobiological studies done there. However, there is a very interesting study of Eskimo that demonstrates that during the winter months, they tend to experience day/night reversal of activity cycles vis-a-vis UTC. That study is: Stern, Pamela. 2003. Upside-Down and Backwards: Time Discipline in a Canadian Inuit Town. Anthropologica 45:147-161. I particularly like the Stern article because it demonstrates the tension between what our bodies want to do and the rhythms structured by UTC + a timezone offset. As I said in my earlier post, what worries me somewhat is biology's uninformed adoption of UTC as if it accurate replicates natural cycles of light and darkness. Unfortunately, I'm less familiar with the literature on annual cycles than I am on circadian cycles. If you want any of the references I mentioned but cannot get them yourself, I can probably find copies and send you .pdf files. If that is the case, you should email me off the list--publishers are persnickety about distribution of electronic copies on list-servs. Cheers, Kevin Kevin K. Birth, Professor Department of Anthropology Queens College, City University of New York 65-30 Kissena Boulevard Flushing, NY 11367 telephone: 718/997-5518 We may live longer but we may be subject to peculiar contagion and spiritual torpor or illiteracies of the imagination --Wilson Harris Tempus est mundi instabilis motus, rerumque labentium cursus. --Hrabanus Maurus On 3/11/15 6:39 PM, Richard Clark rcl...@noao.edu wrote: I'm curious about the repeatability of natural biological cycles. I suspect that most of them are actually triggered by external nonbiological cues rather than being 'biological clocks' in our sense of the word clock. Some that come to mind are annual. The swallows at Capistrano (and the buzzards at Hinkley). I'm not sure how precisely repeatable they actually are vs their popular representation. But one that I have directly observed is the large bat colony under the Campbell Ave bridge over the Rillito in Tucson. During June (Tucson doesn't have weather in June) they come out en mass starting 7-9 minutes after sunset. Very precisely, very repeatably. I imagine the cue is more the illumination level than an internal clock. Also some sort of social or aggrigate behavior may be involved. Later in the summer the mass exit is more diffuse. Some situations of humans adapting (or perhaps not adapting) to other day lengths that come to mind, other than shift work in general, that come to mind are the watch assignments on nuclear subs (repeats after 18 hours on US subs) and mission control operators for the first few months of a newly arived Mars lander (24h 39m). In the case of the Mars operators it's tempting to try to actually adapt to the 24.65 hr day. There can even be enough of them to form a group with some social identity, overlayed on their home life. Talk about problems of where to draw the line between two different timescales! The submariners actually are an isolated social group but 18 hr isn't a period humans are likely
Re: [LEAPSECS] Letters Blogatory
My post was not to suggest that circadian cycles will be affected by leap seconds or their absence as much as to point out that Mr. Folkman's argument is a better argument against mean time than an argument in favor of keeping the leap second. Getting rid of the leap second will probably have no affect on circadian biology. We already mess that up quite thoroughly with artificial lights and UTC with leaps. What getting rid of leap seconds will eventually do is create confusion in the existing biological literature because biologists are generally not attuned to the difference between clock time and environmental cycles--they too often confuse the measure of time with the timing phenomenon observed. So within a century, field primatologists might start challenging the (silly) claim that baboons are active from 9 to 5. The claim is silly because baboons do not tie their activity to clock time, but cycles of daylight, but the literature emphasizes clock time. As to the level of precision applicable to biological processes, since the fastest neural processes are in milliseconds, for complex behaviors, like response to a stimulus, we're probably talking about 10ths of seconds, but this is only applicable to short-term timing mechanisms, not circadian ones. The circadian system is remarkable for its ability to tolerate changing periodicity of light due to weather and variation in Earth's rotation. With regard to cross-continental travel, there was a very interesting study done on win/loss records of professional baseball teams on cross-continental road trips. It actually matters. That study is: RECHT, LAWRENCE, LEW, ROBERT A., SCHWARTZ, WILLIAM J. 1995. Baseball teams beaten by jet lag. Nature 377:583 I do not know of any students that examine N/S travel across latitudes during mid-winter or mid-summer. Cheers, Kevin Kevin K. Birth, Professor Department of Anthropology Queens College, City University of New York 65-30 Kissena Boulevard Flushing, NY 11367 telephone: 718/997-5518 We may live longer but we may be subject to peculiar contagion and spiritual torpor or illiteracies of the imagination --Wilson Harris Tempus est mundi instabilis motus, rerumque labentium cursus. --Hrabanus Maurus On 3/11/15 4:53 PM, Tom Van Baak t...@leapsecond.com wrote: Thanks, Kevin, for your interesting biological perspective. I think the two vocal astronomers on the mailing list, Rob and Steve, will be happy to add your conclusive scientific, .edu-validated, biological expertise to their pro- leap second knowledge base. As you know, I am neither pro or con, but as someone with many cesium clocks along with some mammals (wife, kids, dogs) in my home I wonder, though, if milliseconds per day (~2e-8) or milliseconds per day per century (~5e-13), have measurable effect on biological systems. I always thought that biological systems were more resistant or more adaptive than parts per billion changes. One could explore the effect of cross-continent seasonal migrations, or even cross-country college road-trips. An interesting experiment might be to change local time by an entire hour once or even twice a year and see how long or how quickly humans and domestic pets can adapt. The effect is non-zero. The Q value of that impulse would provide useful support to your conclusions. Or not. The other experiment is to go to Hawaii or Alaska for a week and see the effect that changes in latitude have on diurnal cycles. Having been to both in the past year, I can say it was quite profound and easily measurable at the 10% or maybe (with careful instrumentation and multiple runs by multiple people over many years) at the 1% level. The issue of leap seconds, OTOH, is sort of at the 1e-8 to 1e-9 level. So I wonder if the biological effects you're talking about are perhaps a million times below noise? /tvb - Original Message - From: Kevin Birth kevin.bi...@qc.cuny.edu To: Tom Van Baak t...@leapsecond.com; Leap Second Discussion List leapsecs@leapsecond.com Sent: Wednesday, March 11, 2015 11:59 AM Subject: RE: [LEAPSECS] Letters Blogatory Solar time is good for humans, but as everyone on this list knows, solar time is not the same as mean time or UTC. From a chronobiological perspective, mammals have a small cluster of neurons at the base of the hypothalamus called the suprachiasmatic nucleus (SCN). There are two parts to this structure. The medial portion has a robust free-running rhythm of around 24 hours plus or minus about 15 minutes. The two ventral portions connect to the optic nerve and have no strong rhythm. Instead, the ventral portions work to reset the dorsal part so that the @24 hour rhythm always anticipates the next sunrise regardless of seasonal variations in the length of the daylight period (or the equation of time). One could say that the SCN is an evolutionary adaptation to Earth's foibles. The SCN then operates quite differently from representations of solar time, mean or apparent,
Re: [LEAPSECS] UTC fails
On 12 March 2015 at 05:21, Steve Allen s...@ucolick.org wrote: On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ: The entire purpose of UTC is to provide a single timescale for all human-related activity. And UTC has failed miserably. POSIX says UTC has no leaps. Google says UTC has occasional days with stretches of seconds which are of varying lengths. De facto, there is no single UTC time scale. But what so many miss is that what is needed to fix the problem is very small. 1) Reliably send leap second data out to the world (recently discussed here and at tz-dist) 2) Announce leap seconds a bit further in advance or on a regular schedule 3) Define a time-scale, UT-86400, that roughly follows UTC but always has 86400 second-like subdivisions (as per the Java time-scale) 4) Provide one or more *agreed* and *standardised* mechanisms to map UTC to UT-86400 (eg. UTC-SLS and Google smear) The fact that we don't have a name or agreed standard for the thing that most people want (outside the time-nerd community) is very sad. UT-86400 is a working name, I'm sure someone can think of a better one. The work needed isn't hard. I just wish that rather than destroying a sensible solution to keep us in line with solar days, effort would be put into defining the above. Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UTC fails
Steve, POSIX does not say that UTC has no leaps, it says that POSIX has no UTC (despite the superficial similarity). Joe Gwinn From: Steve Allen s...@ucolick.org To: Leap Second Discussion List leapsecs@leapsecond.com Date: 03/12/2015 01:22 AM Subject:[LEAPSECS] UTC fails Sent by:LEAPSECS leapsecs-boun...@leapsecond.com On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ: The entire purpose of UTC is to provide a single timescale for all human-related activity. And UTC has failed miserably. POSIX says UTC has no leaps. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Letters Blogatory
Brooks Harris wrote: In other words, let them simply stop adjusting for for leap seconds. Let the atomic clocks become progressively more wrong. Whoa! Hold the phone! What do you mean? Adjust TAI's frequency to match Earth?!? No, he's clearly proposing to leave TAI exactly as it is, and just to use it in place of UTC for applications other than civil time. In his view, wrong = disagreeing with solar time. It's clear enough from the sentences that you quoted, but it also refers back to the preceding paragraph, in which he set up the view that the divergence between atomic time and solar time means that one of them is getting progressively more wrong, and showed that he's not satisfied with viewing solar time as the one that's wrong. -zefram ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] UTC fails
On 2015-03-12 11:57 AM, Stephen Colebourne wrote: On 12 March 2015 at 05:21, Steve Allen s...@ucolick.org wrote: On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ: The entire purpose of UTC is to provide a single timescale for all human-related activity. And UTC has failed miserably. POSIX says UTC has no leaps. Google says UTC has occasional days with stretches of seconds which are of varying lengths. De facto, there is no single UTC time scale. But what so many miss is that what is needed to fix the problem is very small. 1) Reliably send leap second data out to the world (recently discussed here and at tz-dist) Yes. That's the crucial missing link. 2) Announce leap seconds a bit further in advance or on a regular schedule Yes. 3) Define a time-scale, UT-86400, that roughly follows UTC but always has 86400 second-like subdivisions (as per the Java time-scale) That's similar to NTP and POSIX. These timescales work just fine for creating broken down time except for the 23:59:60th count (or rollover at 23:59:58) and the fact their absolute seconds offset (time_t) does not include the Leap Seconds. 4) Provide one or more *agreed* and *standardised* mechanisms to map UTC to UT-86400 (eg. UTC-SLS and Google smear) Yes, but not to non-deterministic work-around things like Google Smear! The fact that we don't have a name or agreed standard for the thing that most people want (outside the time-nerd community) is very sad. UT-86400 is a working name, I'm sure someone can think of a better one. Yes, in a way. The mismatch between UTC and the many timescales with 86400 second days one part of the the difficulties. There are many 86400 second day timescales that are not exactly the same (NTP and POSIX, for examples) so there's already many potential names. We do have the Gregorian calendar timescale, but this can't deal with Leap Seconds by itself is related to each of the timescales in different ways. These timescales exist and are in wide use so they can't be pulled back. Gregorian, TAI, and UTC are the closest things to common you're going to get. The work needed isn't hard. I just wish that rather than destroying a sensible solution to keep us in line with solar days, effort would be put into defining the above. Conceptually not difficult depending on who you're talking to, but arriving at consensus for standardization is a whole other matter. It can be done, it needs to be done, but it won't be easy. -Brooks Stephen ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Hi Tom, On 2015-03-12 02:57 AM, Tom Van Baak wrote: Brooks, A couple more comments on your questions. Many timekeeping systems seem to be designed for only indicating now counting forward, including NTP, POSIX, and PTP, taking short-cuts to avoid supplying full Leap Second and local-time metadata. I'm not clear why you call that a short-cut. It's just how clocks works. Right, that's how a traditional clock works but that's fundamentally inadequate when the UTC counting methods are in use. What I meant by short-cut is that the UTC metadata (Leap Second announce and table) are generally not provided or accounted for. NTP and POSIX drop the 23:59:60 count. They work like a traditional clock, not like a UTC clock. They tick forward and there is no requirement that they keep a record of time in the past. Right, Thats' the traditional concept of a clock. But we very much need to calculate durations - how long ago did an event happen?, how long was it between event A and event B?, when is event A scheduled to occur? Traditionally, days were 86400 long, so calculating durations was simple. Days are 86400 long in NTP and POSIX, so calculating durations is simple BUT it doesn't match UTC! How many seconds between 1972-06-30T23:59:59Z (UTC) and 1972-01-01T00:00:00Z (UTC)? Two, not one, because in NTP and POSIX 1972-06-30T23:59:60Z (UTC) went missing. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC. Right, well, typically the objective is to indicate local civil time. Only those jurisdictions at -00:00 offset from the UTC can use UTC, and even then might observe Daylight. Humans care about local civil time - only the timekeepers care about UTC who use it as the reference timescale from which local civil time is derived. Yes, of course, the whole topic of the tz mess is dragged into the calculation, which is outside of UTC timekeeping discussion proper, but still required for practical purpose of indicating local civil time and coordinating activities by those time representations. The only thing a UTC clock requires is advanced notice of the length of the current minute. In principle the announce could be even faster than that to keep counting forward, but to schedule an event in the future you need either the next upcoming Leap Second or how long in the future *we are sure* there will not be a Leap Second. This is required by no later than second 58 in the minute. Right. But for practical reasons a UTC clock typically gets more notice than that, as you know. The more notice you have, the further in the future you can confidently schedule, or predict. Currently the announcements are essentially done by humans. ITU-R Rec 460 says The IERS should decide upon and announce the introduction of a leap-second, such an announcement to be made at least eight weeks in advance. That gives the humans at IERS time to create and publish Bulletin C and presumably all the timekeeper humans enough time to implement the upcoming Leap Second into their time servers or protocols. IERS has done this at least eight weeks in advance. The most recent Bulletin C was issued nearly six months in advance. Note, however, its not clear *exactly when* it was issued. I became aware of it like on Jan 2, but you'd really like to know *exactly* when it was issued. Of course you'd really like to have this notification *automatically* issued and taken up by all time servers, protocols, and applications everywhere. I've never been able to understand why that practice persists despite the obvious need to be able to fully represent the entire post-1972 UTC timescale. The policy and forms of the announce signals and Leap Seconds table are obvious missing links, and its regrettable no official attempt has been made since 1972 to rectify those inadequacies. I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is obvious. As Warner said in another LEAPSEECS post - A clock doesn’t need to know its past. But a time scale is more than just how many seconds the current minute will have. It has a history and to compute elapsed time in that time scale, you need to know its history. You don't have a definition of what your clock means if you don't have a specification of the timescale its representing. For the UTC timescale you need the Leap Second metadata - all of it. A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed. That's why the time codes you
Re: [LEAPSECS] UTC fails
On Mar 13, 2015, at 12:57 AM, Stephen Colebourne scolebou...@joda.org wrote: On 12 March 2015 at 05:21, Steve Allen s...@ucolick.org wrote: On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ: The entire purpose of UTC is to provide a single timescale for all human-related activity. And UTC has failed miserably. POSIX says UTC has no leaps. Google says UTC has occasional days with stretches of seconds which are of varying lengths. De facto, there is no single UTC time scale. But what so many miss is that what is needed to fix the problem is very small. Except that it isn’t. 1) Reliably send leap second data out to the world (recently discussed here and at tz-dist) Doesn’t fix the POSIX time_t issue. 2) Announce leap seconds a bit further in advance or on a regular schedule Ditto. 3) Define a time-scale, UT-86400, that roughly follows UTC but always has 86400 second-like subdivisions (as per the Java time-scale) 4) Provide one or more *agreed* and *standardised* mechanisms to map UTC to UT-86400 (eg. UTC-SLS and Google smear) So UTC is great, except that we need to do this other thing that isn’t UTC because UTC isn’t great? Seems like a lot of effort when dropping leap seconds is a lot easier to implement. The fact that we don't have a name or agreed standard for the thing that most people want (outside the time-nerd community) is very sad. UT-86400 is a working name, I'm sure someone can think of a better one. The work needed isn't hard. I just wish that rather than destroying a sensible solution to keep us in line with solar days, effort would be put into defining the above. So why is keeping us inline with solar days so desirable? The rate of change is so slow and the number of people already out of sync with solar time on the second level is so large it seems like a lot of hassle for not much benefit when DUT1 can be known. Apart from telescopes, nothing really breaks. Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Universal Time works
On Mar 13, 2015, at 8:48 AM, Rob Seaman sea...@noao.edu wrote: On Mar 12, 2015, at 1:04 PM, Warner Losh i...@bsdimp.com wrote: So why is keeping us inline with solar days so desirable? The rate of change is so slow and the number of people already out of sync with solar time on the second level is so large it seems like a lot of hassle for not much benefit when DUT1 can be known. “Seems like a lot of hassle” is not a coherent engineering argument. Proponents of change to such a fundamental standard should quantify the trade-offs and risks before conducting a politicized vote. Few communities have been consulted even now. It is a perfectly valid engineering argument: The cost to do X is exceeded by the benefit. Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
On Mar 12, 2015, at 3:57 PM, Tom Van Baak t...@leapsecond.com wrote: Brooks, A couple more comments on your questions. Many timekeeping systems seem to be designed for only indicating now counting forward, including NTP, POSIX, and PTP, taking short-cuts to avoid supplying full Leap Second and local-time metadata. I'm not clear why you call that a short-cut. It's just how clocks works. They tick forward and there is no requirement that they keep a record of time in the past. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC. The only thing a UTC clock requires is advanced notice of the length of the current minute. This is required by no later than second 58 in the minute. But for practical reasons a UTC clock typically gets more notice than that, as you know. I've never been able to understand why that practice persists despite the obvious need to be able to fully represent the entire post-1972 UTC timescale. The policy and forms of the announce signals and Leap Seconds table are obvious missing links, and its regrettable no official attempt has been made since 1972 to rectify those inadequacies. I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is obvious. A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed. That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table. By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC. A clock doesn’t need to know its past. But a time scale is more than just how many seconds the current minute will have. It has a history and to compute elapsed time in that time scale, you need to know its history. Warner signature.asc Description: Message signed with OpenPGP using GPGMail ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Universal Time works
On Mar 12, 2015, at 1:04 PM, Warner Losh i...@bsdimp.com wrote: So why is keeping us inline with solar days so desirable? The rate of change is so slow and the number of people already out of sync with solar time on the second level is so large it seems like a lot of hassle for not much benefit when DUT1 can be known. “Seems like a lot of hassle” is not a coherent engineering argument. Proponents of change to such a fundamental standard should quantify the trade-offs and risks before conducting a politicized vote. Few communities have been consulted even now. Apart from telescopes, nothing really breaks. Even in astronomy this isn’t true: http://www.cacr.caltech.edu/futureofutc/2011/preprints/36_AAS_11-677_Seaman.pdf And the reason the American Astronautical Society sponsored two meetings on this topic is that there are serious concerns about the impact of redefining UTC on space operations. The Space Community needs to develop a plan for upgrading operational software in case leap second discontinuance goes into effect”: http://www.cacr.caltech.edu/futureofutc/2011/preprints/30_AAS_11-674_Storz.pdf Perhaps the notion is that GNSS makes the obvious air, sea and land navigation issues obsolete, but GNSS itself would incur significant costs. The costs and time needed for the required changes to the operational software and ICDs are unknown at this time, but they are expected to be significant”: http://www.cacr.caltech.edu/futureofutc/2011/preprints/32_AAS_11-675_Malys.pdf If a timescale is created without leap seconds it should be called something other than UTC, as discussed in Torino in 2003. This would preserve UTC (and the widespread concept of Universal Time as an approximation to mean solar time) for backwards compatibility. Many other issues are discussed in: http://www.cacr.caltech.edu/futureofutc/2011/preprints/01_AAS_11-660.pdf Rob Seaman National Optical Astronomy Observatory ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Civil timekeeping before 1 January 1972
Brooks wrote: Many timekeeping systems seem to be designed for only indicating now counting forward, including NTP, POSIX, and PTP, taking short-cuts to avoid supplying full Leap Second and local-time metadata. Warner wrote: A clock doesn’t need to know its past. But a time scale is more than just how many seconds the current minute will have. It has a history and to compute elapsed time in that time scale, you need to know its history. Ok, thanks. So there's a terminology issue among Brooks' timekeeping system, Tom's clock, and Warner's timescale. I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a timescale. There are clock ensemble algorithms. There are time transfer methods. There are time encoding conventions. There are time API's in languages, libraries, or operating systems. WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST). GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO). I'm not trying to pick a fight here. Just trying to seek clarification. I guess I still don't understand what Brooks is trying to sell, or why full historical phase or frequency records are any part of timekeeping, or time transfer. Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele? Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement? I do a lot of timekeeping here, old and new. What time_t looked like before 1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an interest to me. But all the older stuff arrives in the form of faded paper, or JPG photos, or TXT files. I would never think of trying to encode that into some 32 or 64 bit binary format. /tvb ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
