Tom Van Baak said:
> If you want to play it safe perhaps NIST could freeze DUT1 in
> WWV/WWVB at its current value of -0.3 until someone calls to
> ask if there's a problem. If years go by before anyone has an
> issue, then that answers the question.
Even better, why not make it vary wildly, even
In message , "Tom Van Baak" writes:
>If you want to play it safe perhaps NIST could freeze DUT1 in
>WWV/WWVB at its current value of -0.3 until someone calls to
>ask if there's a problem.
The UK 60kHz Rugby transmitter used to do this experiement on
almost every DUT1 change some years back, and t
As I think we've discussed, there are some systems which
cannot handle |DUT1|>0.9 (UK broadcast time, for example).
A number of national timecodes provide DUT1 to one decimal
place. Over here WWV and WWVB are examples. During the
era when sextants were used and when observatories got their
DUT1
On Wed, Aug 3, 2011 at 02:47, Steve Allen wrote:
> ... but the whole point of tz/zoneinfo is to provide that
> kind of tables. Currently we see that ftp://elsie.nci.nih.gov/pub/
> has tzdata2011h.tar.gz , so the politicians and bureaucrats have
> already messed with civil time on 8 occasions dur
>
> So giving us 3 years notice of leap seconds instead of six months
> should be a total no-brainer.
As I think we've discussed, there are some systems which cannot handle
|DUT1|>0.9 (UK broadcast time, for example).
If there is reasonable three year confidence in predicting DUT1, then there i
