> So they effectively create a new time scale which began 2000-01-01,
> which increments with magical SI seconds that presumably are intended
> to have the same length as those in the TT coordinate frame, which is
> presumably intended only to be valid within geostationary orbit
> (Mondiale), yet w
> But this needs a clarification. Standard time replaced local
> apparent solar time in several steps. First, clock (mean) time
> replaced apparent time for civil purposes. As you can see from the
> proliferation of railroad standards, these were both still local to
> one place or another. Late
> If the SI second were properly tuned to the mean solar day, and the
> secular slowing were eliminated, there would be no need to mess about with
> the civil time scale, because the random accelerations and decelerations
> would cancel out in the long run. Of course, we'd have to tolerate larger
> > In fact, leap seconds are simply due to the earth
> > being slow. How it got to be "slow" and whether
> > it is "slowing" are another issue.
>
> Let me see if I have this right:
>
> 1) We have leap seconds because the Earth rotates more slowly
> than once every 86,400 SI seconds.
Yes. (and I k
> To the extent that I understand the point you are
> aiming for, this statement conflates two issues:
>
> 1) that the long term secular deceleration is only
> perceptible as a baseline trend hidden beneath
> large amplitude, short period, effects, and
>
> 2) that leap seconds aren't the result of
> I should perhaps explain that I was interested in an internal
> representation for durations, which I am now representing as a triple of
> months, minutes, and seconds (the number of minutes in a month is not
> predictable, nor the number of seconds in a minute given leap seconds,
> but all other
> UT1 et al are not really measures of time, but of angle (of Terran
> rotation).
To some degree yes, but don't they also include minor
corrections (polar motion, longitude, etc.) and so at one
level they already depart from raw angle measurement
and instead are trying to act like clocks?
/tvb
> Can someone lay out for me exactly what the difference is between
> clock precision and clock resolution? I've read the NTP FAQ and
> several other pages but am more confused than ever.
>
> (I do understand the distinction between precision and accuracy:
> 3.1429493 is \pi precise to 8 significa
> It should be clear that the gaps and repeats are fictitious, especially
> if you think of AEST and AEDT as existing beyond the times when they are
> in legal use. Putting it in practical terms, suppose I have a traffic
> accident at 0230 on 2006/04/02, what time will the police officer write
> i
Michael Sokolov writes:
> I cannot make the beautiful analog clock on the tower show 23:59:60.
> But it's trivial to make it occasionally take 1.1 SI seconds instead of
> 1 SI second to turn its hands by 1 civil second.
Yes, this is one of the awkward features of a leap
second (positive leap secon
> > 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
> 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 discontin
> > You cannot divide timekeeping, time dissemination,
> > into neat stages. In the 1960s if ten labs were told
> > to offset their phase or frequency it affected only a
> > handful of people or systems. Today when IERS
> > announces a leap second, millions of machines,
> > systems, and people are
> Without further debating the meaning of "civil time", consider the
> implications of this two stage system. The first stage conveys TAI
> or something related to it by a constant offset. The second stage at
> any location (correct me if I misunderstand you) would be a secondary
> clock dissemin
> Research-quality telescopes, in particular all the ones built in the last
> few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error
> would be a complex ~10 arcsec error in both axes and give a quite useless
> pointing performance. However, UTC is often used as a UT1 delivery
> sys
> : As I understood it, it was mainly that TAI is a post-factum "postal"
> : timescale.
>
> How is it that UTC can be realized in realtime, but TAI isn't. I
> thought the difference between the two was an integral number of
> seconds, by definition. Is that understanding flawed?
>
> Wanrer
Not f
With the surge of leap second captures this time
around, are there any concerns over the growing(?)
use of double :59 second or double :00 second
instead of :59:60 for a positive leap second?
Although not technically correct, they do seem a
practical, perhaps even clever, alternative -- in some
ca
> > A more apt comparison would be to the leap year rules that we
> > have. We know the rules going
> > forward a thousand years or so.
>
> Apt indeed. Leap seconds are scheduled at least six months in
> advance. That's about one part in 15 million. A thousand year
> horizon for scheduling leap
> The majority of such clocks only run the receiver for some part of
> the day to save power.
>
> One particular kind I examined ran the receiver until it had sync,
> then powered the receiver down for 23 hours and repeated the cycle.
Yes, but the LS bit stays lit for the entire month (at
least fo
It is correct that DUT1 changes by +1.0 across a
positive leap second; going from a negative value
(e.g., -0.6) to a positive value (e.g., +0.4).
You would see the inverse in the case of a negative
leap second (DUT1 will, by definition, be positive
before the negative leap second and go negative
a
Two pages that may be useful this weekend:
Leap Second Countdown Clock
http://www.leapsecond.com/java/nixie.htm
How to Watch a Leap Second
http://www.leapsecond.com/notes/leap-watch.htm
After the weekend let me know if you have photos
or your own links to add to the above collection.
/tvb
> > While you're at it let's change when leaps occur; not
> > just at 23:59:59
> > ...
> I second this too, 23:59:59 is the worst time to
> insert a leap second, since failing to implement it
> leaves you with the wrong day (month and possibly
> year) at the very second it occurs.
Given th
Thanks for the link. I see the reference to it is on their
main page:
https://www.schriever.af.mil/GpsSupportCenter/advisories.htm
Also note the leap second photos they used in the power
point presentation came from:
How to Watch a Leap Second
http://www.leapsecond.com/notes/leap-watch.htm
/tvb
> The same paradigm suggests a new definition of UTC,
> strengthening its link to UT1 down to 0.09s, and
> switching from leap seconds to leap tenths of a
> second. This aims at making leap intervals a rule
> and not an exception. Tens of a second are as easy
> (or as difficult) to
BBC News, 9 November 2005, 08:36 GMT [sic]
http://news.bbc.co.uk/2/hi/science/nature/4420084.stm
"Consideration of a proposal to redefine everyday timekeeping
by scrapping leap seconds - small changes made to clock
time - has been postponed. A working party weighing the
proposed change to Coordin
Demetrios,
I have a list of google "leap second" alerts going back
a year if anyone on the list wants the history.
The other 3 alerts that occasionally give interesting
results are leapsecond, "leap hour", and leaphour.
/tvb
http://www.LeapSecond.com
http://www.LeapHour.com
- Original Messa
> But a GPS receiver which uses the current leap second
> offset (UTC against GPS time) to help guess which 1024
> week period it is in will _eventually_ not work quite
> right.
I guess that begs the question - which of the hundred
GPS receiver manufacturers actually use the LS field
in the UTC su
> So, dropping leap seconds from UTC would cause these receivers
> to, eventually, go back 19 years on cold start? Hardly a major
> catastrophe but worth noting.
Ed,
There are no proposals to "drop leap seconds" as
such. The proposal, as I understand it, is/was to
hold leap seconds at their curr
Warner,
> These instances of overflow come from remainders of division
> operations overflowing. They all can be derived from a single base
> number (say number of seconds since 1970, MJD, etc). However, when
> you are deriving that single base number, it can be much harder.
Yeah, I also prefer
> A cold GPS receiver takes about 20 minutes to get the almanac data
> from the GPS constellation. It is intrinsic to GPS that this is the
> case. You cannot get around this.
It's easy to solve that if the application requires it.
You could get the almanac from an external source;
such as anothe
> In addition, since GPS time is TAI - 19s, the GPS-UTC difference will
> eventually overflow any fixed-sized transmission packet (if transmitted
> as a delta or as a table, it makes no difference in the end).
True, but the GPS signal format has a number of
fixed length fields and they do not caus
Here's a thought on precise time and leap seconds.
The computer I used in college had a refrigerator
sized memory with 32K words and now I have an
iPod with 4 GB. CPU speeds have grown from
below 1 MHz to above 4 GHz. Data rates at my
desk grew from 300 bps to 100 Mbps. Moore's
Law still holds tru
WWV and WWVB and perhaps other national
systems transmit DUT1 as a 3- or 4-bit signed
number of 100 ms. I'm curious what sort of
instruments or operational systems use or used
this value? Several astronomers on the list make
a good case that they depend on UTC being
close enough to UT1 for their wo
> >I don't get the electronic edition either but see:
> >http://www.leapsecond.com/history/wsj2005.htm
> >
> >They twice mentioned 62 o'clock. The history and
> >technical details behind capturing that event are at:
> >http://www.leapsecond.com/notes/leapsec256.htm
>
> And 62 o'clock happened preci
> From: "John Ackermann N8UR"
> To: "Discussion of precise time and frequency measurement"
> The front page of today's Wall Street Journal has an article about the
> debate. The headline is "Why the US wants to End the Link Between Time
> and Sun."
>
> Unfortunately, I don't get the electronic ed
> UTC is a useful approximation to GMT.
Rob, this will always be true, won't it? Whether you
have 100 ms time step adjustments, or 100 x e-10
rate adjustments, leap seconds, or leap hours it
seems to me there has been and will always be an
honest attempt to "coordinate" the two scales.
The questi
Steve,
Some comments on your fine posting...
> But Essen claims for himself (in both this autobiography
> and in Metrologia
I found the Metrologia article interesting. I had heard
of 100 ms steps (leap tenth-seconds) but not the 50
ms steps.
Did you notice he appears to refer to a leap second
w
> It's not a linear curve, it's quadratic. I found some
> slides from the torino meeting where this was laid out very
> well but I didn't save the URL, sorry.
Ah, yes, I forgot the quadratic term. Steve Allen has
a nice page at:
http://www.ucolick.org/~sla/leapsecs/dutc.html
And his table shows
> As seen on my online bibliography web page, the proposal probably was
> a slightly evolved form of this document
>
> http://www.fcc.gov/ib/sand/irb/weritacrnc/archives/nc1893wp7a/1.doc
No one can know for sure but I was wondering if
there is a consensus on when the first leap hour
would occur? E
There have been a number of timing related articles
on Mars recently that got me thinking. Here's my
leap second related question:
Does anyone know if Mars is a better timekeeper
than Earth? Earth's liquid core, polar ice caps,
large moon, oceans, and climate all play a part
in our irregular lengt
> The current GPS data format will fail in approximately 2057, 2079, or
> 2095 for decelerations of 42, 31, or 25.6 s/cy2, respectively.
> In terms of deployed systems, that's Real Soon Now.
Not to worry. It won't fail. The "solution" is simply
to let delta t sub LS in page 18 subframe 4 roll over
Must be a slow news year; here's another one...
http://dsc.discovery.com/news/briefs/20031229/atomicclock.html
At least this article is a lot more accurate than
CNN's and a rare popular article that correctly
distinguishes between rate and deceleration (it
mentions "1.5 milliseconds per century")
> The W1K rollover for GPS was in 1999, and all that year was spent
> testing various systems to see how they would fail. It would not be
> at all surprising if the impending doom of the leap second counter was
> noticed during a review of other deficiencies in the GPS system.
Please see:
Some h
> > Or put it another way, can you think of a single
> > application where GPS cannot already deliver
> > the same TAI as Galileo will someday deliver?
>
> Golly, Tom, it's on your own web page
> http://www.leapsecond.com/pages/saoff/
>
> At the whim of the commander in chief, GPS can turn on Selec
A CNN popular spin on leap seconds:
http://www.cnn.com/2004/TECH/science/01/01/leap.second.ap/index.html
/tvb
http://www.LeapSecond.com
> And Galileo will operate on TAI.
Could someone explain why this factoid has any
bearing on the issue? I've seen this presented
before and it makes no sense to me. GPS also
"operates" on TAI: as I'm sure you all know, by
definition, GPS internal time is TAI - 19 s.
Or put it another way, can you
If you are interested in seeing yesterday's Motorola
Oncore "leap second glitch", I caught it in the act. See:
http://www.leapsecond.com/notes/leapsec256.htm
To be fair with respect to the "leap second issue",
I should point out that other than this premeditated
raw hex Oncore VP trace file, none
Here's another leap second triva that gives a
historical context you might find interesting.
http://www.leapsecond.com/history/wwvb1966.htm
/tvb
Steve,
Can you elaborate on "some reports". I have been
asking this question for years and have not yet
found a definitive answer.
Recently I talked with the power company speaker
at the ION GPS conference about synchronization
-- who appeared very familiar with the issues of grid
phase angle syn
> Here's an interesting product note
> http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf
> These GPS receivers are about to report an erroneous calendar date as
> a result of the long *absence* of leap seconds that has resulted from
> the recent acceleration of the rotation of the cr
> A propos of both the topic and the discussion of notation, I've observed
> that in the U.S., hospitals (where 24-hour notation, or "military time" as
> civilians inevitably call it) are one of the few businesses where wall
> clocks are nearly always set to the correct time (within+/- one minute,
http://www.spaceflight.nasa.gov/shuttle/investigation/timeline/index.html
I've been reading a lot of NASA pages on the shuttle
recently and was reminded once again that NASA
seems to use "GMT" instead of "UTC" to label their
timelines. Do any of you know why?
That brings up another question - has
> Fact 1 is that there is a *lot* of Unix code out there that depends on
> 1 day being represented by a 86400 increment in time_t, and that is what
This is correct. And add DOS, Windows, and NT.
> Fact 2 is that the old 1980s pre-POSIX Unix manuals talked about GMT and
> not UTC. This strongly su
53 matches
Mail list logo
