Re: The real problem with leap seconds
Tim Shepard scripsit: [many sensible opinions snipped] > "leap hours" are a horrible idea, whether they be leap hours inserted > in to some UTC-like global standard, or by local jurisdictions. I understand what's wrong with the former kind, but what's wrong with the latter? Why do you think they are more of a problem than DST shifts? -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing [EMAIL PROTECTED] has so much been paid by so manyhttp://www.ccil.org/~cowan to so few! (pace Winston Churchill) http://www.reutershealth.com
Re: The real problem with leap seconds
> > I still think NTP should have distribute TAI, but I understand using > > Was your failure to form a past-participle a Freudian slip? I'm with you > if you really mean "NTP should distribute TAI"!!! Uh, probably yes. I didn't even see the grammer error when I re-read it the first time just now. About 15 years ago I came to believe that it would have been better if NTP distributed TAI instead of (or perhaps alongside) UTC. And yes, I still believe that. Now I think it would be best if TAI and UTC were both distributed by time signals (and NTP, etc), with equal emphasis to make it clear to all users that they have a choice to make. Atomic time based on the SI second (TAI) and traditional time based on earth orientation (UT) are both needed in the modern world. Both should be distributed. People who have some need to synchronize clocks should be forced to decide which kind of time would be best for them. (Or perhaps in some cases it would be best for them to implement both side-by-side in their system.) A system which distributes TAI (which never has leap seconds) and also distributes the current number of seconds of offset for UTC, as well as leap warnings (or continuously broadcasts the table of all known (past and scheduled) leap seconds), would seem to be reasonable. This would allow the decisions about what would be the best time scale to use to be made downstream. Build good mechanisms that allow a variety of policies, and leave policies to those downstream of you. My preference would be for civil time keeping to continue to be tied to earth orientation, as it was when GMT was the standard. So UT1 or UTC would continue to be "normal" time, and TAI (or something like it) would be the "weird" time that certain geeks care about. The other alternative would be for civil timekeeping to be based on TAI (something which never has leap seconds), with UTC (or something like it) to be the "weird" time that certain geeks care about. This is the radical proposal, but I can understand that some would want to do this. If humans spread out to other places besides the earth, an earth-centric time scale might begin to seem somewhat quaint. Distributing leap second information to a Mars colony seems kind of silly. (Though I guess that those on a Mars colony would in fact care about earth orientation, e.g. if they wished to communicate with friends back on Earth using their amateur laser-communication gear in their backyards.) I very much dislike the proposal to *redefine* UTC to abolish leap seconds. I dislike very much trying to understand code that was written with descriptive names (for variables, functions, constants, etc) but which has evolved such that what the names apparently mean and what they really mean are very different. UTC is a type of UT time. If you stop putting leap seconds in UTC to keep it close to all the other UT time scales, then it no longer deserves to have a name that starts with UT. So fine, if we must stop maintaining UTC with leap seconds and move civil time keeping users to some sort of new standard, please do *not* call it UTC after the change. The hack of having UTC ticks align with TAI ticks and adjusting UTC with leap seconds was perhaps not the best idea. But it was done, and has been in place for more than 30 years, and is now a widely implemented and understood standard. If this hack should be replaced with something better (and perhaps it should be), I'd want 20 years advance notice that a change is coming, and 15 years advance notice as to what exactly the change will be. (I suspect though I won't get that much notice.) "leap hours" are a horrible idea, whether they be leap hours inserted in to some UTC-like global standard, or by local jurisdictions. Well, those are my opinions. Thanks for listening. -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
On Mon, 9 Jan 2006, Tim Shepard wrote: wot, no attribution of quotes? > > >and you still cannot even get it [TAI] reliably from your > > I still think NTP should have distribute TAI, but I understand using Was your failure to form a past-participle a Freudian slip? I'm with you if you really mean "NTP should distribute TAI"!!! Pete.
Re: MJD and leap seconds
On Jan 10, 2006, at 11:06 AM, Poul-Henning Kamp wrote: Let me see if understood that right: In order to avoid computing problems and to get precise time, astronomers rely on a timescale without leapseconds, because the Earths rotation is too unstable a clock for their purposes. Just like everybody else, astronomers rely on interval time when interval time is needed and rely on earth orientation "time" when earth orientation is needed. The particular irony is that these two purposes may be mistaken one for the other. In a technical arena, there is no more ambiguity here than in many other issues. Define the requirements for a particular project and crunch the numbers and design an experiment or apparatus that does what it needs to do. In a civil/business/international/legal historical context, one of the requirements (you will disagree, but please try to make your own case, not just blow holes in mine) is that only a single realization of timekeeping may be supported. Ambiguity and conflict are inevitable as a result. Our goal is to manage the balance between these appropriately. Rob
Re: MJD and leap seconds
In message <[EMAIL PROTECTED]>, Rob Seaman writes: >> 2. Julian Date (JD) >> >> [...] For that >> purpose it is recommended that JD be specified as SI seconds in >> Terrestrial Time (TT) where the length of day is 86,400 SI seconds. Let me see if understood that right: In order to avoid computing problems and to get precise time, astronomers rely on a timescale without leapseconds, because the Earths rotation is too unstable a clock for their purposes. And in N years, for some value of N, JD's will start at midnight instead of noon in Greenwich. "Don't do like we do, do as we say..." Yes, the irony is rather notable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: MJD and leap seconds
On Jan 10, 2006, at 9:17 AM, Peter Bunclark wrote:On Tue, 10 Jan 2006, Poul-Henning Kamp wrote:In message <[EMAIL PROTECTED]>, Peter Bunclark writes: Good grief. MJD is used widely in astronomy, for example in variablility studies where you want a real number to represent time rather than deal with the complications of parsing a date.So how do you deal with fractional days in that format ? with decimals.I'm not one to shy away from irony (see! just proved it again...), but I do think there is a real issue here. Was interested to read the pages Tom pointed us to. Both the IAU position and McCarthy's exposition of same are curiously silent about the issue of resolving ambiguities resulting from non-denumerable SI intervals and solar days.The IAU tells us:1. Julian day number (JDN)The Julian day number associated with the solar day is the number assigned to a day in a continuous count of days beginning with the Julian day number 0 assigned to the day starting at Greenwich mean noon on 1 January 4713 BC, Julian proleptic calendar -4712.2. Julian Date (JD)The Julian Date (JD) of any instant is the Julian day number for the preceding noon plus the fraction of the day since that instant. A Julian Date begins at 12h 0m 0s and is composed of 86400 seconds. To determine time intervals in a uniform time system it is necessary to express the JD in a uniform time scale. For that purpose it is recommended that JD be specified as SI seconds in Terrestrial Time (TT) where the length of day is 86,400 SI seconds.Which is to say that day number is (always) a solar unit and fraction of day (sometimes) an SI unit.In "practical" terms, a JD(TT) _expression_ would simply be calculated by running a count of TT seconds since some epoch through the obvious conversion mill, but we're then returned to the central issue of reconciling such a JD(TT) with a JD(UT1). A calculation would simply show a growing fractional difference between the two, of course. At issue is the unit jump in JDN. Which day is it? This ambiguity only holds for a bit over a minute a "day" in the current epoch. (UTC = TAI - 33s, TT = TAI + 32.184s) The ambiguity is growing.Perhaps the SI unit should have been called the "essen", rather than the "second", as Steve Allen has said. But whatever it is called, it has a clear definition. But what is the definition of a day? Am convinced we need to reach a consensus on this before leaping (irony again) into any changes to the current rules of civil/business/international/legal/historical date and timekeeping.You'll note that I omitted "technical" and "scientific" from that list. This is not now and has never been a discussion about resolving purely technical issues, although some of the implications strongly affect technical people.Rob
Re: MJD and leap seconds
On Tue, 10 Jan 2006, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Peter Bunclark writes: > >On Tue, 10 Jan 2006, Tom Van Baak wrote: > >> have no leap seconds. Astronomers appear to avoid > >> using MJD altogether. > > > >Good grief. MJD is used widely in astronomy, for example in variablility > >studies where you want a real number to represent time rather than deal > >with the complications of parsing a date. It tends to be written into the > >FITS header of practically every data file observed. > > So how do you deal with fractional days in that format ? with decimals. Pete.
Re: MJD and leap seconds
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >On Tue, 10 Jan 2006, Tom Van Baak wrote: >> have no leap seconds. Astronomers appear to avoid >> using MJD altogether. > >Good grief. MJD is used widely in astronomy, for example in variablility >studies where you want a real number to represent time rather than deal >with the complications of parsing a date. It tends to be written into the >FITS header of practically every data file observed. So how do you deal with fractional days in that format ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: MJD and leap seconds
> > have no leap seconds. Astronomers appear to avoid > > using MJD altogether. > > Good grief. MJD is used widely in astronomy, for example in variablility > studies where you want a real number to represent time rather than deal > with the complications of parsing a date. It tends to be written into the > FITS header of practically every data file observed. > > Pete. OK, my information was dated. It was my impression from reading lots of metrology papers and a few astronomy papers that the timing folks almost always use MJD while astronomers almost always use JD. There was also something about the IAU and [mis]use of MJD. I see now the deeper IAU MJD story is covered at: http://hbar.phys.msu.ru/gorm/ahist/juldate.htm and RESOLUTION B1: ON THE USE OF JULIAN DATES http://www.iers.org/iers/earth/resolutions/UAI_b1.html http://www.iers.org/MainDisp.csl?pid=98-110 Thanks for the clarification. /tvb
Re: MJD and leap seconds
On Tue, 10 Jan 2006, Tom Van Baak wrote: > have no leap seconds. Astronomers appear to avoid > using MJD altogether. Good grief. MJD is used widely in astronomy, for example in variablility studies where you want a real number to represent time rather than deal with the complications of parsing a date. It tends to be written into the FITS header of practically every data file observed. Pete.
Re: MJD and leap seconds
> I've had many heated arguments with co-workers about what the right > thing to do here. Do you compute the day as if it had an extra > second, thus breaking the ability to subtract two MJD numbers to get a > meaningful elapsed time? Or, do you ignore the leap second entirely, > giving discontinuity around the leap second? > > In the end, we opted to report MJD and HH:MM:SS. > > Warner I am familiar with the arguments. I think your solution is a good one. The goal is to remove ambiguity and your using both MJD and UTC (or TAI) does that. It's always a pain to compute accurate time intervals when leap seconds have to be considered. Strictly speaking MJD (= JD - 240.5) is based on an astronomical timescale such as UT1. In this case a leap second has no effect since the UT timescales have no leap seconds. Astronomers appear to avoid using MJD altogether. The time metrology community, on the other hand, uses MJD a lot and in practice it's based on UTC. And so one can ponder, as you mentioned, if the fractional MJD value for 12/31/2005 should be based on a 86400 s or 86401 s day. The advice I was given was to just leave the ambiguity alone; unless it really, really mattered, in which case you the author should specify which timescale which you are basing your MJD on, or not use MJD at all. I've never run into a case myself where it mattered, nor seen a paper where a graph axis or numerical result depended in which timescale the MJD values were based on. It is interesting to note that if leap seconds were to be eliminated the ambiguity between a true UT-based MJD and a practical UTC-based MJD would be further exposed. Still, if you consider how the timing community generally uses MJD I suspect you'd have to look hard to find a graph that would be off by as much as one pixel. The other approach is the space and timing communities could by accident or convention redefine MJD as a UTC-based time value, leaving JD to the astronomers as a true, pure UT-based time value. It's just one of many subtle but non-showstopper details that would show up in the next centuries if leap seconds were retired. /tvb http://www.leapsecond.com/time-nuts.htm
