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
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
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
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
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: 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: 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
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
