GMT: UT1 vs UTC
Ian G Batten
Come the winter, for us in the UK date(1) reports:
Thu Oct 30 11:01:15 GMT 2003
when in fact for almost everyone's computers it's UTC, which is +/- 0.9s
from GMT. And the `Greenwich Time Signal' on the radio is UTC(GPS)
these days, too. Does anyone have a clock which actually ticks UT1?
ian
Terje Mathisen
Why would you want one?
Even in England/Great Britain GMT is just a local name for UTC these days.
UT1 is for astronomers, as well as a way to figure out when/if to
add/subtract leap seconds.
BTW, anyone want to bet how much (supposedly leap-second handling) gear
will fall down if we actually have to subtract a leap second?
Terje
--
- <Terje.M...@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
Ian G Batten
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> Ian G Batten wrote:
>
> > Come the winter, for us in the UK date(1) reports:
> >
> > Thu Oct 30 11:01:15 GMT 2003
> >
> > when in fact for almost everyone's computers it's UTC, which is +/- 0.9s
> > from GMT. And the `Greenwich Time Signal' on the radio is UTC(GPS)
> > these days, too. Does anyone have a clock which actually ticks UT1?
>
> Why would you want one?
>
> Even in England/Great Britain GMT is just a local name for UTC these days.
It would be interesting to challenge your phone or electricity bill on
the basis that the rate changes were `wrong'. Legally I think GMT is
still UT1 --- the bill to redefine it as UTC didn't pass in 1997.
ian
David L. Mills
If we ever had to give back a leapsecond, it would be a disaster. The
WWV/WWVB timecode has only a single bit to signal leap insertion and no
way to signal deletion. The GPS timecode has the UTC-GPS offset in
seconds, but the GPS receivers I have indicate only leap insertion. From
the ERTS data the rate of increase has flattened out over the past thre
years, which certainly gives me the willies, but my professional friends
tell me not to worry about it.
Dave
f...@nowhere.fr
> Terje,
> If we ever had to give back a leapsecond, it would be a disaster. The
> WWV/WWVB timecode has only a single bit to signal leap insertion and no
> way to signal deletion. The GPS timecode has the UTC-GPS offset in
> seconds, but the GPS receivers I have indicate only leap insertion. From
> the ERTS data the rate of increase has flattened out over the past thre
> years, which certainly gives me the willies, but my professional friends
> tell me not to worry about it.
http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html
clearly shows this flattening.
-- François Meyer
Tel : (+33) 3 81 66 69 27 Fax : 3 81 66 69 44
Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE
**** Université de Franche-Comté ****** CNRS UMR 6091 *****
David J Taylor
news:3FA14136...@udel.edu...
> Terje,
>
> If we ever had to give back a leapsecond, it would be a disaster. The
> WWV/WWVB timecode has only a single bit to signal leap insertion and no
> way to signal deletion. The GPS timecode has the UTC-GPS offset in
> seconds, but the GPS receivers I have indicate only leap insertion. From
> the ERTS data the rate of increase has flattened out over the past thre
> years, which certainly gives me the willies, but my professional friends
> tell me not to worry about it.
>
> Dave
Dave - may I have your permission to quote your statement in an article
about timekeeping on PCs that I have written?
Thanks,
David
Rob Seaman
http://www.ucolick.org/~sla/leapsecs
His bibliography, http://www.ucolick.org/~sla/leapsecs/onlinebib.html,
is especially useful.
Ian G. Batten says:
> Come the winter, for us in the UK date(1) reports:
>
> Thu Oct 30 11:01:15 GMT 2003
>
> when in fact for almost everyone's computers it's UTC, which is +/- 0.9s
> from GMT. And the `Greenwich Time Signal' on the radio is UTC(GPS)
> these days, too.
I would hardly refer to the current Unix/Posix/Linux date command as any
sort of fundamental source of time :-) What is really happening here,
of course, is that "GMT" is simply your local time zone. If I ask for
the date in Tucson, I get:
Thu Oct 30 10:38:03 MST 2003
If I ask for universal time (date -u), I get various answers:
Thu Oct 30 17:39:56 UTC 2003 (from Linux), but
Thu Oct 30 17:40:10 GMT 2003 (MacOS X)
Thu Oct 30 17:40:27 GMT 2003 (Solaris)
Thu Oct 30 17:40:15 GMT 2003 (SunOS)
In those cases that both GMT and UTC are mentioned in the web page for
date, they are described as synonyms:
"Display the date in GMT (universal time)."
"Coordinated Universal Time is often called "Greenwich Mean Time"
(GMT) for historical reasons."
Often the approximation is implicitly assumed - the man page refers to
Universal Time and issuing the "date -u" command reports GMT. The fact
is that Universal Time (of all flavors, including UT1 and UTC) has always
been taken to refer to an approximation to Greenwich Mean Time. This is
a very useful approximation that should not be lightly discarded.
Ian further wonders:
> Does anyone have a clock which actually ticks UT1?
UT1 is only known after the fact when observations can be consulted to
derive the precise Earth orientation at a given epoch (and also remove
the higher order terms that go into UT2). That said, the precision
timing community's predictions of UT1 have become exceedingly accurate.
Take a look at Figure 2 from http://iraf.noao.edu/~seaman/leap. (In the
interest of full disclosure, you'll note that I have an axe to grind :-)
Astronomical observatories sometimes do present clocks to the personnel
in their control rooms that display UTC corrected by the current DUT
value to report UT1 to within 0.1s. More often, however, the clocks
simply present UTC while internal operations for pointing the telescope
and tracking objects and other utility chores include the DUT correction.
Can anyone comment on whether commercial clocks are available that
include the DUT correction? This would seem a prerequisite before any
action might be taken to decommission the leap second and retire UTC as
the international civil time standard.
Terje Mathisen says:
> Why would you want one?
Good question. For many purposes raw UTC suffices. An approximation
of the Earth's orientation to one second of time is often adequate.
For some purposes, it is not. On the other hand, why would anybody
want any precision source of time? Is your statement that precision
time is only useful for marking relative intervals? I would suggest
that absolute standards of time are important for many purposes.
> Even in England/Great Britain GMT is just a local name for UTC these days.
Legally this is not true, as Ian points out:
> Legally I think GMT is still UT1 --- the bill to redefine it as UTC
> didn't pass in 1997.
Imagine reintroducing such bills in countries around the world - with
the express (or hidden?) intent being to get each country to switch
from GMT to UTC simply such that UTC can be later stripped of any
underlying connection to the spinning Earth. Should make great
theater on C-SPAN - at 3:00 am :-(
Terje continues:
> UT1 is for astronomers, as well as a way to figure out when/if to
> add/subtract leap seconds.
UT1, and Universal Time in general, is for everybody - at some level
of approximation. There is indeed an initiative among the precision
timing community to eliminate leap seconds. Such a move would
eventually turn day into night (literally). Everybody on the planet -
for all activities - cares at some level. The current arguments for
such a (rather silly, in my estimation) change key on suggestions that -
for instance - nobody cares about daylight saving time so nobody will
care about the elimination of leap seconds. The flaw here - a flaw
that has been repeated many times during the Kabuki-like leap second
debates - is to confuse periodic effects (not just Spring Forward, but
ALSO Fall Back) with secular effects (UTC being allowed to diverge
indefinitely from GMT). (The latter could even be interpreted as the
Prime Meridian being allowed to drift out to sea.) Folks most certainly
would care if clocks were set forward another hour every spring and then
never set back.
It's also just plain weird for the precision timing community to rally
around a proposal to make the civil time standard completely imprecise.
> BTW, anyone want to bet how much (supposedly leap-second handling) gear
> will fall down if we actually have to subtract a leap second?
And how much "gear" will fail if we don't?
http://www.motorola.com/ies/GPS/docs_pdf/notification_oncore.pdf
(As Steve Allen points out, "It is rumored that these [GPS] receivers
may be built into some JDAM smart bombs and other munitions.")
We live on a rotating Earth that is spinning down. That is a reality
that our institutions and infrastructure can't ignore.
David L. Mills says:
> If we ever had to give back a leapsecond, it would be a disaster. The
> WWV/WWVB timecode has only a single bit to signal leap insertion and no
> way to signal deletion. The GPS timecode has the UTC-GPS offset in
> seconds, but the GPS receivers I have indicate only leap insertion. From
> the ERTS data the rate of increase has flattened out over the past thre
> years, which certainly gives me the willies, but my professional friends
> tell me not to worry about it.
We don't have leap seconds because the Earth's rotation is slowing down -
we have leap seconds because it has already slowed down over the century
since the equatorial epoch of 1900. The figure labeled "Figure 1" from
http://iraf.noao.edu/~seaman/leap shows this trend. It would take much
more than the Earth's deceleration flattening out temporarily (a third
or fourth order effect) to overcome such an accumulated lever arm.
This would, however, be a good opportunity to redesign WWV and GPS and NTP
to be actually responsive to the technical requirements of the underlying
time standards.
Rob Seaman
National Optical Astronomy Observatory
Tucson, Arizona USA
David L. Mills
Sure. I got quoted for a soundbite on the local news radio station about
how computers deal with daylight/standard time switchine. I told the
interviewer computers didn't care, since they run on Universal
Coordinated Time (UTC). She was notably unimpressed. By the time I told
her about leapseconds, her microphone glazed over.
Dave
Terje Mathisen
> Terje,
>
> If we ever had to give back a leapsecond, it would be a disaster. The
> WWV/WWVB timecode has only a single bit to signal leap insertion and no
> way to signal deletion. The GPS timecode has the UTC-GPS offset in
> seconds, but the GPS receivers I have indicate only leap insertion. From
> the ERTS data the rate of increase has flattened out over the past thre
> years, which certainly gives me the willies, but my professional friends
> tell me not to worry about it.
I do worry, the recent firmware bug (one-second glitch) on my Oncore,
caused by a missing leap second, makes me quite confident that a
negative leap second would indeed be a disaster.
Terje Mathisen
> http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html
>
> clearly shows this flattening.
Very instructive!
With hindsight, which almost by definition is hard to get, it would have
been better to delay the last leap second by 6-18 months, that way the
current gap wouldn't have exposed that Oncore firmware bug.
f...@nowhere.fr
> f...@nowhere.fr wrote:
>> http://hpiers.obspm.fr/eop-pc/earthor/utc/leapsecond.html
>>
>> clearly shows this flattening.
> Very instructive!
> With hindsight, which almost by definition is hard to get, it would have
> been better to delay the last leap second by 6-18 months, that way the
> current gap wouldn't have exposed that Oncore firmware bug.
Terje,
Do you have some more information on that bug ?
Which firmware is implied on which version of the oncore ?
Where can I find informations on the mechanism of the bug ?
Thank you in advance.
my email is fmeyer at obs-besancon dot fr
-- Francois Meyer (Please, no html, no MSWord attachment)
Terje Mathisen
> UT1 is only known after the fact when observations can be consulted to
> derive the precise Earth orientation at a given epoch (and also remove
> the higher order terms that go into UT2). That said, the precision
> timing community's predictions of UT1 have become exceedingly accurate.
> Take a look at Figure 2 from http://iraf.noao.edu/~seaman/leap. (In the
> interest of full disclosure, you'll note that I have an axe to grind :-)
No problem, I happen to agree totally: Both that leap seconds is the
only reasonable way to handle the issue, and that any changes should be
limited to making the current system better.
I believe going to a monthly schedule would also break quite a bit of
sw/hw, but even a quarterly schedule for leap seconds would suffice to
reduce the maximum offsets quite a bit.
>>Why would you want one?
>
> Good question. For many purposes raw UTC suffices. An approximation
> of the Earth's orientation to one second of time is often adequate.
> For some purposes, it is not. On the other hand, why would anybody
Afaik, not being an astronomer like you, the standard procedure is to
use the current UTC, or if known, UT1 approximation, to point the
telescopes in approximately the correct direction, then do any remaining
fine-tuning by selection of one or more calibration stars.
I.e. effectively generating the local UT time scale, corrected also for
stuff like temperature or Earthquake-caused twisting of the base of the
observatory, right?
>>Even in England/Great Britain GMT is just a local name for UTC these days.
>
> Legally this is not true, as Ian points out:
>
>>Legally I think GMT is still UT1 --- the bill to redefine it as UTC
>>didn't pass in 1997.
Ouch!
"We are British, we don't care that we really don't have a choice, we're
still not going to accept any kind of externally mandated rule."
>
> Imagine reintroducing such bills in countries around the world - with
> the express (or hidden?) intent being to get each country to switch
> from GMT to UTC simply such that UTC can be later stripped of any
> underlying connection to the spinning Earth. Should make great
> theater on C-SPAN - at 3:00 am :-(
>
> Terje continues:
>
>>UT1 is for astronomers, as well as a way to figure out when/if to
>>add/subtract leap seconds.
>
> UT1, and Universal Time in general, is for everybody - at some level
> of approximation. There is indeed an initiative among the precision
> timing community to eliminate leap seconds. Such a move would
I was one of those who wrote comments to that "initiative":
Sometimes it is much better to do nothing, this is definitely one of
those times.
David J Taylor
>
> Sure. I got quoted for a soundbite on the local news radio station about
> how computers deal with daylight/standard time switchine. I told the
> interviewer computers didn't care, since they run on Universal
> Coordinated Time (UTC). She was notably unimpressed. By the time I told
> her about leapseconds, her microphone glazed over.
>
> Dave
Thanks, Dave. I will use your quote, then.
Please don't get me started about the non-critical, non-scientific
approach to things these days...........
Cheers,
David
Tim Shoppa
> seconds, but the GPS receivers I have indicate only leap insertion.
The HP 58503A/Z3801A/Z3816A, all with Motorola Oncore GPS receivers inside
them, supposedly can return either positive or negative or no adjustments
in their T2 message. I'll have to watch what these say at bug-time on
11/28/03.
Tim.
Terje Mathisen
> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>>With hindsight, which almost by definition is hard to get, it would have
>>been better to delay the last leap second by 6-18 months, that way the
>>current gap wouldn't have exposed that Oncore firmware bug.
>
>
> Terje,
>
> Do you have some more information on that bug ?
Only what was posted here, use Google!
f...@nowhere.fr
>> Terje Mathisen <terje.m...@hda.hydro.com> wrote:
>>>With hindsight, which almost by definition is hard to get, it would have
>>>been better to delay the last leap second by 6-18 months, that way the
>>>current gap wouldn't have exposed that Oncore firmware bug.
>>
>>
>> Terje,
>>
>> Do you have some more information on that bug ?
> Only what was posted here, use Google!
oops. I read Rob's message after yours. Sorry.
-- Francois Meyer
Michael Shields
Terje Mathisen <terje.m...@hda.hydro.com> wrote:
> With hindsight, which almost by definition is hard to get, it would
> have been better to delay the last leap second by 6-18 months, that
> way the current gap wouldn't have exposed that Oncore firmware bug.
Although the Oncore is important, I don't think it would be a good
precedent to start adjusting international timescales to work around
bugs in one vendor's product.
--
Shields.
David L. Mills
You scratch a beef I've held for some years. The GPS message includes
the offset of UTC from GPS time and we know the offset of GPS from TAI.
The timecode delivered to the driver should be in UTC and the leap
information should include the TAI offset in deciseconds. This would
seem to satisfy everybody and make the leapseconds file now provided by
NTP unnecessary.
Dave
David L. Mills
We can do this. Provisions are in the nanotime kernel interface to
return the TAI seconds offset in the ntp_gettime() routine. We could
format that offset in deciseconds instead. It would not be hard to
modify the clock drivers to include the DUT1 value and add this to the
offset from the leapseconds file. Is this worth doing?
Geeze, I suppose we could determine the TDB correction from the
geographic position (with a little help from an almanac) and return that
as well. Somebody should volunteer a driver for the stepper motors that
drive you telescope, which would then become completely automatic. This
would be an interesting class project.
Dave
Terje Mathisen wrote:
...
> Afaik, not being an astronomer like you, the standard procedure is to
> use the current UTC, or if known, UT1 approximation, to point the
> telescopes in approximately the correct direction, then do any remaining
> fine-tuning by selection of one or more calibration stars.
>
> I.e. effectively generating the local UT time scale, corrected also for
> stuff like temperature or Earthquake-caused twisting of the base of the
> observatory, right?
...
Terje Mathisen
Sorry, I didn't want to imply that!
As noted on one of those pages, Leap seconds used to be added
preemptively, i.e. quite a while before the 0.5 second offset point,
instead of closer to the final 0.9 second limit.
The last leap second we had was added 6-12 months too early, if the goal
had been to minimize the UTC-UT1 at all times.
David L. Mills
Take a look at the DUT1 format in the WWV/H/B timecode. Only three bits
plus signbits, so at least those stations tank out over +-0.7 s. A leap
has to be programmed before the DUT1 gets to 0.7 s.
Dave
Terje Mathisen
> Terje,
>
> Take a look at the DUT1 format in the WWV/H/B timecode. Only three bits
> plus signbits, so at least those stations tank out over +-0.7 s. A leap
OK, good to know!
> has to be programmed before the DUT1 gets to 0.7 s.
I still wasn't clear enough: It seems like the last leap second was
added as soon as possible, i.e. at the point where the resulting offset
would presumably just fit into the 0.7 s allowance.
Half a year or maybe even a full year later would both have been closer
to the halfway (0.5 s) point.
Anyway, it _really_ doesn't matter today, what's done is done.
Wolfgang S. Rupprecht
> I do worry, the recent firmware bug (one-second glitch) on my Oncore,
> caused by a missing leap second, makes me quite confident that a
> negative leap second would indeed be a disaster.
If only Motorola would offer the raw GPS time (along with the GPS-UTC
offset) this wouldn't be much of an issue. I wonder why all the
clock-chip (and gps) manufacturers insist on handing one Y-M-D H:M:S
and then making one convert back to a useful number.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
The From: address is valid. Don't mess with it.
irony: when the richest man in the world is struck using Microsoft products
Terje Mathisen
>>I do worry, the recent firmware bug (one-second glitch) on my Oncore,
>>caused by a missing leap second, makes me quite confident that a
>>negative leap second would indeed be a disaster.
>
>
> If only Motorola would offer the raw GPS time (along with the GPS-UTC
> offset) this wouldn't be much of an issue. I wonder why all the
> clock-chip (and gps) manufacturers insist on handing one Y-M-D H:M:S
> and then making one convert back to a useful number.
OTOH, converting from seconds since epoch to date is the hard one, doing
Y-M-D H:M:S to seconds is much easier.
Tom Van Baak
> If we ever had to give back a leapsecond, it would be a disaster. The
> WWV/WWVB timecode has only a single bit to signal leap insertion and no
> way to signal deletion. The GPS timecode has the UTC-GPS offset in
Dave,
Not true. Yes, there is only a single bit in the
WWV/WWVB timecode to indicate a pending
leap second but the sign and magnitude of the
UT1 correction bits tell you if the leap second is
positive or negative. For WWVB these are bits
36/37/38 for the sign and bits 40/41/42/43 for
the magnitude.
For example, for the 6/30/1997 leap second the
UT1 correction was -0.5 before the leap second
and +0.5 after the leap second. Similarly for the
12/31//1998 leap second the UT1 correction was
-0.3 before and +0.7 after the leap second.
When the net change in UT1 correction is +1.0
the leap second will be positive and if the net
change is -1.0 it will be a negative leap second.
So a separate bit for positive/negative leap second
is not needed in the specification.
I'm not saying there won't be hardware or software
trouble elsewhere if a negative leap second were
ever to occur, but the WWV/WWVB time code
specification itself is not a limitation.
For details on the leap second examples above see:
http://www.leapsecond.com/notes/ls-wwvb-97.htm
http://www.leapsecond.com/notes/ls-wwvb-98.htm
Tim Shoppa
> > I do worry, the recent firmware bug (one-second glitch) on my Oncore,
> > caused by a missing leap second, makes me quite confident that a
> > negative leap second would indeed be a disaster.
>
> If only Motorola would offer the raw GPS time (along with the GPS-UTC
> offset) this wouldn't be much of an issue.
Isn't GPS time what you get if you use the Motorola binary command set "@@Aw"
option with UTC Time Correction disabled? And I think you still can
get the offset with "@@Bo" even if UTC has been disabled.
> I wonder why all the
> clock-chip (and gps) manufacturers insist on handing one Y-M-D H:M:S
> and then making one convert back to a useful number.
Are you talking about NEMA mode maybe? I will agree that NEMA time
handling is pretty sucky (even if it does work 99.99999999% of the time...)
Tim.
Michael Sierchio
> ... Yes, there is only a single bit in the
> WWV/WWVB timecode to indicate a pending
> leap second but the sign and magnitude of the
> UT1 correction bits tell you if the leap second is
> positive or negative.
Positive? Negative? Leap seconds? Let's call the
whole thing off. TAI as the base timescale, puhleeze,
people! It would save a lot of heartache and nonsense
(uh, with due respect to Dr. Feynman, on a macrocosmic
scale, is time not monotonic? I thought so)
Wolfgang S. Rupprecht
sho...@trailing-edge.com (Tim Shoppa) writes:
> Isn't GPS time what you get if you use the Motorola binary command set "@@Aw"
> option with UTC Time Correction disabled? And I think you still can
> get the offset with "@@Bo" even if UTC has been disabled.
Interesting. I hadn't known about the @@Aw or @@Bo command.
Too bad Motorola didn't include a manual with my m12-oncore kit back
when I bought it in early 2000. All I found described on the web were
a few core commands like @@Ha. (Which I fed to mktime(3) to get a
seconds-since-the-epoch.)
>> I wonder why all the
>> clock-chip (and gps) manufacturers insist on handing one Y-M-D H:M:S
>> and then making one convert back to a useful number.
>
> Are you talking about NEMA mode maybe? I will agree that NEMA time
> handling is pretty sucky (even if it does work 99.99999999% of the time...)
@@Ha also has the time broken down in the least useful units for
computer work.
struct Ha_data {
...
/* date */
B1 month;
B1 day;
B2 year;
/* time */
B1 hour;
B1 minutes;
B1 seconds;
B4 nano_seconds;
...
}
Is there a better way to get a seconds since the epoch?
David L. Mills
The typo should have been WWV/WWVH, not WWV/WWVB. WWVB does have a leap
warning (bit 56), a four-bit DUT1 magnitude (bits 40-43) and three (!)
DUT1 sign (bits 36-38). The WWV/WWVH timecode has a leap warning (bit
3), a three-bit DUT1 magnitude (bits 56-58) and DUT1 sign (bit 50).
However, you raise an interesting idea. The on-time epoch is the
beginning of the minute that the timecode is actually sent. From the
leap warning you know the epoch that a leap must be made and in the
previous minute the DUT1 sign. From this you can predict the DUT1 after
the leap and thus the leap correction. Clever. I'm still worried about
the three-bit DUT1 magnitude in WWV/WWVH.
Notwithstanding the above, I was told by NIST staff that the NIST
timecode generators do not implement a negative step. I have no
information about other stations.
See http://www.boulder.nist.gov/timefreq/stations/wwvbtimecode.htm.
Dave
Tom Van Baak wrote:
>
[content deleted due facsist news system]
Tom Van Baak
> beginning of the minute that the timecode is actually sent. From the
> leap warning you know the epoch that a leap must be made and in the
> previous minute the DUT1 sign. From this you can predict the DUT1 after
> the leap and thus the leap correction. Clever. I'm still worried about
Correct. But it's even less fragile than that.
1) By convention you know that the leap second
will occur at the end of the last minute of a month.
2) You know what month it will be because the
leap second pending bit goes on and stays on
weeks ahead of time.
3) You also know months (or even years) ahead
of time what the DUT1 sign is.
So 1+2+3 allows you to know well in advance
when and what type of leap second it will be.
Thus there's no requirement to be following the
timecode during the exact minute before the leap
second. Which is a good thing because it is likely
you won't have good reception anyway.
By the way, this is a much better situation than
the DST bits. WWVB-based atomic time radio
controlled clocks that don't happen to get good
reception the night before a DST change will not
make the change when they are supposed to.
> the three-bit DUT1 magnitude in WWV/WWVH.
Is not bit 50 the DUT1 sign for WWV/WWVH? See:
http://www.boulder.nist.gov/timefreq/stations/wwvtimecode.htm
> Notwithstanding the above, I was told by NIST staff that the NIST
> timecode generators do not implement a negative step. I have no
> information about other stations.
That's correct. Which is why it's important to state
that the WWVB subcode spec itself is fine; it's various
pieces of hardware (including the Ft Collins TCG) and
end-user software than may not be prepared for a
negative leap second should one ever be scheduled.
Terje Mathisen
> Positive? Negative? Leap seconds? Let's call the
> whole thing off. TAI as the base timescale, puhleeze,
> people! It would save a lot of heartache and nonsense
> (uh, with due respect to Dr. Feynman, on a macrocosmic
> scale, is time not monotonic? I thought so)
The only real problem, as has been observed by lots and lots of people
before me, is that we would like to use a single time scale to measure
two different things:
1) TAI-style monotonically increasing equal-sized seconds
2) Calendar events, tied to the Earths motion around the Sun.
This simply isn't possible, at least not perfectly and for future dates,
because it means that you must at least be able to predict exactly which
values the Earth Rotation guys are going to measure.
Tim Shoppa
> >> clock-chip (and gps) manufacturers insist on handing one Y-M-D H:M:S
> >> and then making one convert back to a useful number.
> >
> > Are you talking about NEMA mode maybe? I will agree that NEMA time
> > handling is pretty sucky (even if it does work 99.99999999% of the time...)
>
> @@Ha also has the time broken down in the least useful units for
> computer work.
>
> struct Ha_data {
> ...
>
> /* date */
> B1 month;
> B1 day;
> B2 year;
>
> /* time */
> B1 hour;
> B1 minutes;
> B1 seconds;
> B4 nano_seconds;
>
> ...
> }
>
>
> Is there a better way to get a seconds since the epoch?
@@Bp returns a 32-bit integer for the seconds in the Epoch, but I'm unclear
on whether this is useful for our purposes or not. It might be the
timestamp for ionospheric data? And it seems to be in UTC, not GPS time.
HP Z3801A's use Oncores internally, and the Z3801A T1-format timestamp returns
a hex string corresponding to the number of GPS seconds since 6-Jan-1980.
I am surprised to find that the Oncore itself doesn't make a message in this
kind of clothing - it seems like it'd be easy to do.
Tim.
David L. Mills
>
> 3) You also know months (or even years) ahead
> of time what the DUT1 sign is.
> So 1+2+3 allows you to know well in advance
> when and what type of leap second it will be.
>
> Thus there's no requirement to be following the
> timecode during the exact minute before the leap
> second. Which is a good thing because it is likely
> you won't have good reception anyway.
I didn't mean to imply required reception during the minute before the
leap. In fact, the WWV/H reference clock driver makes no such
assumption, just that the leap bit (and presumably DUT1) have been
previously received and available at the leap epoch.
...
> > the three-bit DUT1 magnitude in WWV/WWVH.
>
> Is not bit 50 the DUT1 sign for WWV/WWVH? See:
>
> http://www.boulder.nist.gov/timefreq/stations/wwvtimecode.htm
As I said previously, the three-bit DUT1 magnitude field can encode only
0-7 deciseconds of either sign. So far as I remember, the DUT1 has never
exceeded +-7 deciseconds before a leap is taken.
Dave