What is your point?
An rf gnss simulator is routinely used to check critical (old) GPS recerivers for week rollover issues and leapsecond scenarios at work.
? ? ?Bj?rn
-------- Originalmeddelande --------
Fr?n: Steve Allen
Datum:2015-03-02 05:51 (GMT+01:00)
Till: Leap Second Discussion List
Rubrik: [LEAPSECS] prevarication?
An op-ed in GPS World suggest the use of a GNSS simulator
http://gpsworld.com/expert-advice-a-leap-into-the-unknown/
I wonder if attributing "prevarication" to the ITU-R was the best word.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From seaman at noao.edu Mon Mar 2 08:59:46 2015
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 2 Mar 2015 06:59:46 -0700
Subject: [LEAPSECS] prevarication?
In-Reply-To:
References:
Message-ID:
>> Fr?n: Steve Allen
>> Datum:2015-03-02 05:51 (GMT+01:00)
>> Till: Leap Second Discussion List
>> Rubrik: [LEAPSECS] prevarication?
>>
>> An op-ed in GPS World suggest the use of a GNSS simulator
>>
>> http://gpsworld.com/expert-advice-a-leap-into-the-unknown/
>>
>> I wonder if attributing "prevarication" to the ITU-R was the best word.
> On Mar 2, 2015, at 12:09 AM, Bj?rn wrote:
>
> What is your point?
>
> An rf gnss simulator is routinely used to check critical (old) GPS recerivers for week rollover issues and leapsecond scenarios at work.
>
> Bj?rn
Most would find a GNSS simulator a wise purchase independently of leap seconds.
Some might suspect prevarication to be parapraxis for procrastination.
Rob
From cfuhb-acdgw at earthlink.net Mon Mar 2 19:32:51 2015
From: cfuhb-acdgw at earthlink.net (Paul Hirose)
Date: Mon, 02 Mar 2015 16:32:51 -0800
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150301133754927511.b6cf3588@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
Message-ID: <54F50133.3000609@earthlink.net>
>
I recommend Leap Second Handling (1), "Enumeration of UTC seconds when
inserting a leap second" be modified to half second steps:
2015-06-30 23:59:59.0
2015-06-30 23:59:59.5
2015-06-30 23:59:60.0
2015-06-30 23:59:60.5
2015-07-01 00:00:00.0
2015-07-01 00:00:00.5
2015-07-01 00:00:01.0
That makes clear the correct notation for events inside a leap second.
From martin.burnicki at meinberg.de Tue Mar 3 16:05:11 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Tue, 03 Mar 2015 22:05:11 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150301171038516345.d9f27407@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net>
Message-ID: <54F62207.1070706@meinberg.de>
Joseph Gwinn wrote:
> Harlan,
>
> On Sun, 01 Mar 2015 20:35:20 +0000, Harlan Stenn wrote:
>> Joseph Gwinn writes:
>>> 1. Slide titled "Known Bugs (2)": Has support for negative leap
>>> seconds been restored in NTP v4? It wasn't clear.
>>
>> Not yet. It's a tradeoff.
>>
>> We've never needed to delete a leapsecond and depending on who you ask
>> it will probably never happen.
>
> So long as UTC can do negative leaps, and the Earth is a wobbly clock,
> the possibility is always with us.
I absolutely agree. It would have been better to fix this (in case it
didn't work) than to remove the code which supported negative leap seconds.
In the 7 year interval where no leap second was required/scheduled I
heard several people saying we might have needed a negative leap second.
Fortunately we didn't, but I still think it's better to prepare for it,
if possible than just ignore it and even remove existing support.
GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm
not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has
no flag defined to announce a negative leap second, so there would be
major problems if one had to be inserted.
>> If we add the code to handle it, we increase complexity, potentially add
>> in a (pretty small) abuse vector (a bad actor could find a way to tell
>> your system to delete a second), and make some small demands on the test
>> framework that we want to have.
>
> The abuse vector argument is pretty weak -- the attacker could just as
> well add a leap second. In both cases, one is off by a second. So, I
> would submit that it's support for leap seconds that provides the
> attack surface, and the area of that surface is not reduced by
> elimination of negative leap seconds.
Again, I strongly agree.
>> If we don't have it and we end up needing it, that causes different
>> problems.
>>
>> There is a parallel issue about folks who cannot or do not upgrade their
>> software. Over 1100 issues were addressed between 4.2.6 and 4.2.8 and
>> people still think 4.2.6 should be "good enough" for them.
>
> Certainly in my world, changing software is a big deal, because one
> needs to rerun all the regression tests. Changing NTP isn't as big a
> deal as changing the OS or the C++ compiler and/or libraries, but still
> people are wary.
>
>
>> We've probably fixed about 3000 issues since 4.2.0 and people still run
>> that.
>>
>> We don't have numbers for the number of bugs fixed between xntp3.5f,
>> xntp3-5.86.5, ntp-4.0, ntp-4.1.{0,1,2}, and ntp-4.2.0.
>>
>> These older releases are still running out there, too.
>
> And don't forget NTPv3 - bet lots of those still run.
>
> Once people get a system to work, they don't tend to go fixing things
> that ain't broke.
Yep.
Martin
--
Martin Burnicki
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Tue Mar 3 16:06:28 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Tue, 03 Mar 2015 22:06:28 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F50133.3000609@earthlink.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F50133.3000609@earthlink.net>
Message-ID: <54F62254.3090508@meinberg.de>
Paul Hirose wrote:
>>
>>
>
> I recommend Leap Second Handling (1), "Enumeration of UTC seconds when
> inserting a leap second" be modified to half second steps:
>
> 2015-06-30 23:59:59.0
> 2015-06-30 23:59:59.5
> 2015-06-30 23:59:60.0
> 2015-06-30 23:59:60.5
> 2015-07-01 00:00:00.0
> 2015-07-01 00:00:00.5
> 2015-07-01 00:00:01.0
>
> That makes clear the correct notation for events inside a leap second.
Good idea! I think I'll pick this up for future versions of the slides.
Thanks,
Martin
--
Martin Burnicki
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Tue Mar 3 15:56:42 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Tue, 03 Mar 2015 21:56:42 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150301133754927511.b6cf3588@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
Message-ID: <54F6200A.7060906@meinberg.de>
Joseph Gwinn wrote:
> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
>> Hi folks,
>>
>> I've been asked off list to make the slides of my presentation at
>> FOSDEM 2015 in Brussels available and post the download link on this
>> list.
>>
>> So here it is:
>>
>
>>
>> See the "Attachment" link.
>
> Very interesting; thanks for posting this.
>
> I have a few questions and comments:
>
> 1. Slide titled "Known Bugs (2)": Has support for negative leap
> seconds been restored in NTP v4? It wasn't clear.
I have to admit that I wrote this before 4.2.8 had been released.
Support for negative leap second has been in older NTP versions, but had
been removed in 4.2.6.
Now in 4.2.8 the leap second code has been reworked and cleaned up, and
a very quick look at the source code seems to indicate that this might
work again. At least there's code which passes the announcement flag to
the kernel, if kernel support is enabled.
I think I'll give it a try soon. I'd expect that a negative leap second
might work if an appropriate announcement is received from a refclock or
upstream NTP server, but it will be interesting to find out if this
works with a NIST-style leap second file where the TAI offset decreases
at a given date.
> 2. Slide titled ""Possibilities for Future Improvements (2)": In the
> wish list for a kernel call to ask if the kernel runs UTC or TAI, a
> couple of issues come to mind. First, many systems set the GPS
> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System
> Time option may be needed.
Yes.
Though I would prefer using TAI instead of raw GPS time if a linear time
scale is required. What if you use a different GNSS receiver, e.g. for
Galileo, or the Chinese Beidou?
GPS time (or whatever) is fine in closed projects/environments, but IMO
a UTC and TAI are the "global" time scales, while GPS is specific to the
U.S.
> Second, we often have the GPS (or PTP 1588)
> receiver to emit GPS System Time, but never share this with downstream
> servers, who are configured for UTC (but strangely the leap seconds
> never come). The difference between UTC and GPS System Time is handled
> in applications code. The reason for this approach is so that the bulk
> of the system is free from step discontinuities, and only the
> interfaces need deal with UTC.
I agree, but as I've tried to point out above I think a better project
design would have been to use TAI instead of GPS time. PTP works
natively with TAI, and you can easily convert between he two scales.
Of course it's easy to convert GPS to TAI, and vice versa, but you have
to take care that more types of conversions are required and implemented
correctly.
Thanks for your feedback!
Martin
--
Martin Burnicki
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Tue Mar 3 16:26:42 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Tue, 03 Mar 2015 21:26:42 +0000
Subject: [LEAPSECS] FW: Rescheduled: Leap seconds webinar - 10 March 2015
Message-ID:
An HTML attachment was scrubbed...
URL:
From hmurray at megapathdsl.net Tue Mar 3 17:31:13 2015
From: hmurray at megapathdsl.net (Hal Murray)
Date: Tue, 03 Mar 2015 14:31:13 -0800
Subject: [LEAPSECS] My FOSDEM slides
Message-ID: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
> GPS time (or whatever) is fine in closed projects/environments, but IMO a
> UTC and TAI are the "global" time scales, while GPS is specific to the U.S.
Since GPS time is a fixed offset from TAI, it's easy to convert.
My vote would be to use TAI rather than GPS wherever you are trying to avoid
leap seconds.
(If you are dealing with GPS itself rather than time in general, it might
make sense to use GPS time consistently throughout a project.)
--
These are my opinions. I hate spam.
From dot at dotat.at Tue Mar 3 19:04:10 2015
From: dot at dotat.at (Tony Finch)
Date: Wed, 4 Mar 2015 00:04:10 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F6200A.7060906@meinberg.de>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
Message-ID:
Martin Burnicki wrote:
>
> I agree, but as I've tried to point out above I think a better project design
> would have been to use TAI instead of GPS time. PTP works natively with TAI,
> and you can easily convert between he two scales.
I don't understand this paragraph. The three timescales you mention have
totally different formats:
TAI: YYYY-MM-DD T HH:MM:SS
PTP: SSSSSSSSSS
GPS: WWWW SSSSSS
They have different epochs:
TAI: 1958-01-01 T 00:00:00 Z
PTP: 1970-01-01 T 00:00:00 Z
GPS: 1980-01-06 T 00:00:00 Z
So I don't see how it makes sense to argue that PTP is more like TAI than
GPS time.
Tony.
--
f.anthony.n.finch http://dotat.at/
Irish Sea: West 6 to gale 8, decreasing 4. Moderate or rough. Showers. Good.
From stenn at ntp.org Tue Mar 3 19:43:29 2015
From: stenn at ntp.org (Harlan Stenn)
Date: Wed, 04 Mar 2015 00:43:29 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
References: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID:
Hal Murray writes:
>
> > GPS time (or whatever) is fine in closed projects/environments, but IMO a
> > UTC and TAI are the "global" time scales, while GPS is specific to the U.S
> .
>
> Since GPS time is a fixed offset from TAI, it's easy to convert.
>
> My vote would be to use TAI rather than GPS wherever you are trying to avoid
> leap seconds.
>
> (If you are dealing with GPS itself rather than time in general, it might
> make sense to use GPS time consistently throughout a project.)
The Generl Timestamp API supports multiple timescales, so if there is a
GPS timescale that's easy. If other satellite systems use different
timescales then that's perfectly OK too.
As long as there's a way to map these to/from a canonical form
(currently TAI) then we should be fine.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
From tvb at LeapSecond.com Tue Mar 3 20:10:47 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Tue, 3 Mar 2015 17:10:47 -0800
Subject: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
Message-ID: <91FD778F6BE34B6798233E19A6BC246A@pc52>
http://gpsworld.com/beidou-numbering-presents-leap-second-issue/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From sla at ucolick.org Tue Mar 3 21:23:37 2015
From: sla at ucolick.org (Steve Allen)
Date: Tue, 3 Mar 2015 18:23:37 -0800
Subject: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
In-Reply-To:
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
Message-ID: <20150304022337.GA20843@ucolick.org>
On Wed 2015-03-04T00:04:10 +0000, Tony Finch hath writ:
> They have different epochs:
>
> TAI: 1958-01-01 T 00:00:00 Z
> PTP: 1970-01-01 T 00:00:00 Z
> GPS: 1980-01-06 T 00:00:00 Z
Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967)
A.R. Robins had been talking with Sadler and Smith and with that
information in hand he wrote that atomic time was identical to UT2 at
1958-01-01 T 20:00:00 Z
This, of course, disagrees with Guinot's memoir, but the various
realizations of UT2 then differed by centiseconds and the different
versions of atomic time were subsequently realigned by milliseconds.
And that date of 1958-01-01 was decided ex post facto at the 1959
August meetings where the US and UK decided to try coordinating their
broadcast time signals using cesium. So there really isn't an epoch
for TAI.
On Tue 2015-03-03T14:31:13 -0800, Hal Murray hath writ:
> Since GPS time is a fixed offset from TAI, it's easy to convert.
I believe that BIPM would disagree because of the different kinds of
steering at the nanosecond level. The stance of the BIPM was expressed in
http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf
where TAI "should not be considered as an alternative time reference."
Without the assent of the BIPM it is hard for there to be an agreed
upon name for real-time versions of time scales that are trying to
track the value of TAI (which will not actually be available until the
next issue of Circular T).
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From tvb at LeapSecond.com Tue Mar 3 22:06:58 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Tue, 3 Mar 2015 19:06:58 -0800
Subject: [LEAPSECS] My FOSDEM slides
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
Message-ID: <6419860708DD473D85F53BD75EA8EDB4@pc52>
> GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm
> not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has
> no flag defined to announce a negative leap second, so there would be
> major problems if one had to be inserted.
Both WWVB and DCF-77 have a single leap second warning bit. With WWVB you look at the sign of DUT1 to know if the leap is insert or delete. So WWVB is fine.
DCF-77 has no DUT1 or leap gender bit so, yes, there will be trouble. I'm sure PTB will figure something out if it ever comes to that.
/tvb
From michael.deckers at yahoo.com Wed Mar 4 02:12:53 2015
From: michael.deckers at yahoo.com (michael.deckers)
Date: Wed, 04 Mar 2015 07:12:53 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F62207.1070706@meinberg.de>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
Message-ID: <54F6B075.5010601@yahoo.com>
On 2015-03-03 21:05, Martin Burnicki wrote about
negative leap seconds:
> In the 7 year interval where no leap second was required/scheduled I heard
> several people saying we might have needed a negative leap second.
Fortunately, this is not a matter of speculation. An easy way to
see the trend of UT1 - UTC is to look at DUT1 (published in
Bulletin D). DUT1 is an approximation to UT1 - UTC and has
always stepped down (except, of course, at positive leap seconds),
ever since the earliest Bulletin D available on the web (1991-06-20).
Before a negative leap seconds would be scheduled, we would see
DUT1 stepping up several times in a row, so there _is_ some
advance warning.
Michael Deckers.
From brooks at edlmax.com Wed Mar 4 02:17:06 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 04 Mar 2015 02:17:06 -0500
Subject: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
In-Reply-To: <20150304022337.GA20843@ucolick.org>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<20150304022337.GA20843@ucolick.org>
Message-ID: <54F6B172.7000603@edlmax.com>
On 2015-03-03 09:23 PM, Steve Allen wrote:
> On Wed 2015-03-04T00:04:10 +0000, Tony Finch hath writ:
>> They have different epochs:
>>
>> TAI: 1958-01-01 T 00:00:00 Z
>> PTP: 1970-01-01 T 00:00:00 Z
>> GPS: 1980-01-06 T 00:00:00 Z
Using ISO 8601 style date and time representation on the TAI timescale
and on the UTC timescale before 1972-01-01T00:00:00Z (UTC) is dangerous
without qualification or explanation.
The "Z" implies its on the UTC timescale. It is controversial when the
term "UTC" came into use. It is controversial if the UTC timescale
existed prior to 1972-01-01T00:00:00Z (UTC), and if it did, exactly what
it is..
"TAI: 1958-01-01 T 00:00:00 Z" - By preceding it with "TAI" we guess
you mean the TAI timescale if we ignore the Z.
1958-01-01T00:00:00 (TAI) is the origin of the TAI timescale, as per
ITU-R Rec 460.
Using pure Gregorian calendar counting method, 1958-01-01T00:00:00 (TAI)
is exactly (1972-1958 = 14 years * 365 = 5110 days + 3 leap year days =
5113 days * 86400 seconds = 441763200 seconds) before
1972-01-01T00:00:00 (TAI).
"PTP: 1970-01-01 T 00:00:00 Z" - The PTP Epoch is defined as
1970-01-01T00:00:00 (TAI) *on the TAI timescale*. Using pure Gregorian
calendar counting method, 1970-01-01T00:00:00 (TAI) is exactly
(1972-1970 = 2 years * 365 = 730 days + 0 leap year days = 730 days *
86400 seconds = 63072000 seconds) before 1972-01-01T00:00:00 (TAI).
"GPS: 1980-01-06 T 00:00:00 Z" - The GPS Epoch is properly and firmly on
the UTC timescale, after 1972-01-01T00:00:00Z (UTC). There's no
controversy there. The GPS Epoch is 1980-01-06T00:00:00Z (UTC) =
1980-01-06T00:00:19 (TAI). From there they count in uninterrupted weeks.
Meantime (always fun to use that expression in a discussion of
timescales :-) ), POSIX "the epoch" is stated as "January 1, 1970
Coordinated Universal Time (UTC)". It is controversial if UTC existed
before 1972. So, to get to that date from 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10 (TAI) we need to constuct some proleptic timescale
before 1972-01-01T00:00:00Z (UTC). I'm not sure what we'd like to call
this proleptic timescale, lets call it "POSIX" for now. Using Gregorian
calendar counting, 1970-01-01T00:00:00 (POSIX) is (1972-1970 = 2 years *
365 = 730 days + 0 leap year days = 730 days * 86400 seconds = 63072000
seconds) before 1972-01-01T00:00:00Z (UTC).
Similarly for NTP. RFC 5905 states ".. the prime epoch, or base date of
era 0, is 0 h 1 January 1900 UTC". Again, lets call this proleptic
timescale "NTP". So, 1900-01-01T00:00:00 (NTP) is (1972 - 1900 = 72
years * 365 = 26280 days + 17 leap year days = 26297 days * 86400
seconds = 2272060800 seconds) before 1972-01-01T00:00:00Z (UTC).
Our "POSIX" timescale overlaps our "NTP" timescale - they exist on the
same timescale proleptic to 1972-01-01T00:00:00Z (UTC) using the the
Gregorian calendar counting method. I got flamed for calling it
"proleptic UTC". What should it be called? After all its used all the
time, shouldn't we have a name for it?
> Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967)
> A.R. Robins had been talking with Sadler and Smith and with that
> information in hand he wrote that atomic time was identical to UT2 at
> 1958-01-01 T 20:00:00 Z
ITU-R Rec 460 says "TAI .. from the origin 1 January 1958 (adopted by
the CGPM 1971)".
In 'Metrologia - leap second: its history and possible future' -
http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf - we read:
"In conformity with the recommendations of IAU Commissions 4 and 31 in
1967, the CCDS [80] defined the origin so that TAI would be in
approximate agreement with UT2 on 1 January 1958, 0 h UT2. The 14th CGPM
approved the establishment of TAI in 1971."
As I interpret this, while there were previous historic uses of
"1958-01-01" as an epoch for various things, including LORAN and early
development atomic timescales, TAI didn't officially exist until 1971,
and by adopting 1958-01-01T00:00:00 (TAI) as the TAI origin they
acknowledged those precedents and made the definition specific and
official on the TAI timescale. Whatever the values or accuracies may
have been for previous "1958-01-01" epochs, this act established the
modern version accurately tied to the TAI timescale.
Is that how you see it?
>
> This, of course, disagrees with Guinot's memoir, but the various
> realizations of UT2 then differed by centiseconds and the different
> versions of atomic time were subsequently realigned by milliseconds.
> And that date of 1958-01-01 was decided ex post facto at the 1959
> August meetings where the US and UK decided to try coordinating their
> broadcast time signals using cesium. So there really isn't an epoch
> for TAI.
Seems to me there is, as above.
>
> On Tue 2015-03-03T14:31:13 -0800, Hal Murray hath writ:
>> Since GPS time is a fixed offset from TAI, it's easy to convert.
> I believe that BIPM would disagree because of the different kinds of
> steering at the nanosecond level. The stance of the BIPM was expressed in
> http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf
> where TAI "should not be considered as an alternative time reference."
>
> Without the assent of the BIPM it is hard for there to be an agreed
> upon name for real-time versions of time scales that are trying to
> track the value of TAI (which will not actually be available until the
> next issue of Circular T).
Well, really, UTC is a dissemination of TAI encoded with the UTC Leap
Second counting scheme - you need only convert from UTC to TAI, which is
easy if (a big if) you have the Leap Second information and apply it
properly.
-Brooks
>
> --
> Steve Allen WGS-84 (GPS)
> UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
> 1156 High Street Voice: +1 831 459 3046 Lng -122.06015
> Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From michael.deckers at yahoo.com Wed Mar 4 02:42:46 2015
From: michael.deckers at yahoo.com (michael.deckers)
Date: Wed, 04 Mar 2015 07:42:46 +0000
Subject: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
In-Reply-To: <20150304022337.GA20843@ucolick.org>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<20150304022337.GA20843@ucolick.org>
Message-ID: <54F6B776.909@yahoo.com>
On 2015-03-04 02:23, Steve Allen wrote on the
epoch of TAI:
> Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967)
> A.R. Robins had been talking with Sadler and Smith and with that
> information in hand he wrote that atomic time was identical to UT2 at
> 1958-01-01 T 20:00:00 Z
>
> This, of course, disagrees with Guinot's memoir, but the various
> realizations of UT2 then differed by centiseconds and the different
> versions of atomic time were subsequently realigned by milliseconds.
> And that date of 1958-01-01 was decided ex post facto at the 1959
> August meetings where the US and UK decided to try coordinating their
> broadcast time signals using cesium. So there really isn't an epoch
> for TAI.
Well, there is not only personal recollections:
RECOMMENDATION S 4 (1970) of the 5th Session of the
Consultative Committee for the Definition of the Second:
4. The origin of International Atomic Time is
defined in conformance with the recommendations
of the International Astronomical Union (13th
General Assembly, Prague, 1967) that is, this scale
was in approximate agreement with 0 hours UT2
January 1, 1958.
Michael Deckers.
From sla at ucolick.org Wed Mar 4 03:13:33 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 4 Mar 2015 00:13:33 -0800
Subject: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS
In-Reply-To: <54F6B776.909@yahoo.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
<20150304022337.GA20843@ucolick.org> <54F6B776.909@yahoo.com>
Message-ID: <20150304081333.GA23363@ucolick.org>
On Wed 2015-03-04T07:42:46 +0000, michael.deckers via LEAPSECS hath writ:
> On 2015-03-04 02:23, Steve Allen wrote on the
> >Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967)
> >A.R. Robins had been talking with Sadler and Smith and with that
> >information in hand he wrote that atomic time was identical to UT2 at
> >1958-01-01 T 20:00:00 Z
> Well, there is not only personal recollections:
>
> RECOMMENDATION S 4 (1970) of the 5th Session of the
> Consultative Committee for the Definition of the Second:
> 4. The origin of International Atomic Time is
> defined in conformance with the recommendations
> of the International Astronomical Union (13th
> General Assembly, Prague, 1967) that is, this scale
> was in approximate agreement with 0 hours UT2
> January 1, 1958.
A resolution does not change what had been done by the folks running
the broadcasts over a decade earlier, nor does it repair the
deficiencies in what they had done over that entire interval. A.R.
Robins talked with H.M. Smith. Smith had been there making the UK
time broadcasts happen. If Smith said that the UK versions of the
atomic time scale and the UT2 time scale were aligned at 1958-01-01T20
then that is likely the way the calculations to do that alignment were
performed, and likely based on the hour of the day that the
ionospheric conditions were most conducive to allowing the best
comparison with other transmitters.
It is instructive to read BIH Bulletin Horaire for the actual history;,
to see the ways that the radio broadcasters attempted, succeeded, and
failed at their mandate of maintaining continuously operating
transmitters based on continuously operating chronometers; to see the
issues with Anna Stoyko's initial, painstaking efforts to reconstruct
the history of received radio time signals into the first atomic time
scale; to see the number of times that the broadcasters changed their
strategies and the number of times that the BIH changed their
algorithms and recomputed what past issues should have said the time
was.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From brooks at edlmax.com Wed Mar 4 04:07:02 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 04 Mar 2015 04:07:02 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F6B075.5010601@yahoo.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
<54F6B075.5010601@yahoo.com>
Message-ID: <54F6CB36.6040502@edlmax.com>
On 2015-03-04 02:12 AM, michael.deckers via LEAPSECS wrote:
>
> On 2015-03-03 21:05, Martin Burnicki wrote about
> negative leap seconds:
>
>> In the 7 year interval where no leap second was required/scheduled I
>> heard
>> several people saying we might have needed a negative leap second.
>
> Fortunately, this is not a matter of speculation. An easy way to
> see the trend of UT1 - UTC is to look at DUT1 (published in
> Bulletin D). DUT1 is an approximation to UT1 - UTC and has
> always stepped down (except, of course, at positive leap seconds),
> ever since the earliest Bulletin D available on the web (1991-06-20).
>
> Before a negative leap seconds would be scheduled, we would see
> DUT1 stepping up several times in a row, so there _is_ some
> advance warning.
>
We can't predict the future. It's fascinating to read about the many
factors affecting Earth's rotation. It seems the largest one is the one
we know least about - the Earth's core. I wonder what DUT1 would have
looked like around the time of the Chicxulub impactor.
Negative Leap Seconds have been a feature of the specification since the
beginning. It gives a little more margin to accommodate the unknown, and
it's not an onerous complication. I hope we concentrate on helping get
implementations to conform to the UTC specs as they stand rather than
look for justifications to over simplify the problem.
-Brooks
> Michael Deckers.
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From sdaoden at yandex.com Wed Mar 4 07:28:54 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Wed, 04 Mar 2015 13:28:54 +0100
Subject: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
In-Reply-To: <91FD778F6BE34B6798233E19A6BC246A@pc52>
References: <91FD778F6BE34B6798233E19A6BC246A@pc52>
Message-ID: <20150304122854.IN2lDQnS%sdaoden@yandex.com>
"Tom Van Baak" wrote:
|http://gpsworld.com/beidou-numbering-presents-leap-second-issue/
Ok, but if engineers don't even get enough time from the business
people to read manuals before they code the software then all bets
are off. From a coders point of view 0-6 seems to be more logical
than 1-7. (I personally, e.g., get more complex awk(1) coding
almost always wrong in the first place because of base 1 not 0.)
--steffen
From sdaoden at yandex.com Wed Mar 4 07:46:41 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Wed, 04 Mar 2015 13:46:41 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <91FD778F6BE34B6798233E19A6BC246A@pc52>
References: <91FD778F6BE34B6798233E19A6BC246A@pc52>
Message-ID: <20150304124641.2Vs4guq_%sdaoden@yandex.com>
|> GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm
|> not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has
|> no flag defined to announce a negative leap second, so there would be
|> major problems if one had to be inserted.
|
|Both WWVB and DCF-77 have a single leap second warning bit. \
|With WWVB you look at the sign of DUT1 to know if the leap \
|is insert or delete. So WWVB is fine.
|
|DCF-77 has no DUT1 or leap gender bit so, yes, there will \
|be trouble. I'm sure PTB will figure something out if it ever comes to that.
While at it the PTB could take the leadership and, after having
dropped distributing the signed UT1-UT difference in 1977 (says
Wikipedia), start distributing the TAI-UTC difference in the same
slot, thus offering atomic time and civil time over DCF-77.
--steffen
From joegwinn at comcast.net Wed Mar 4 08:54:00 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Wed, 4 Mar 2015 08:54:00 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F6200A.7060906@meinberg.de>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
Message-ID: <20150304085400160181.f241e70a@comcast.net>
On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
>>> Hi folks,
>>>
>>> I've been asked off list to make the slides of my presentation at
>>> FOSDEM 2015 in Brussels available and post the download link on this
>>> list.
>>>
>>> So here it is:
>>>
>>
>>>
>>> See the "Attachment" link.
>>
>> Very interesting; thanks for posting this.
>>
>> I have a few questions and comments:
>>
>> 1. Slide titled "Known Bugs (2)": Has support for negative leap
>> seconds been restored in NTP v4? It wasn't clear.
>
> I have to admit that I wrote this before 4.2.8 had been released.
> Support for negative leap second has been in older NTP versions, but
> had been removed in 4.2.6.
>
> Now in 4.2.8 the leap second code has been reworked and cleaned up,
> and a very quick look at the source code seems to indicate that this
> might work again. At least there's code which passes the announcement
> flag to the kernel, if kernel support is enabled.
>
> I think I'll give it a try soon. I'd expect that a negative leap
> second might work if an appropriate announcement is received from a
> refclock or upstream NTP server, but it will be interesting to find
> out if this works with a NIST-style leap second file where the TAI
> offset decreases at a given date.
Hell - lots of code can't handle a positive leap second, so what hope
is there?
>> 2. Slide titled ""Possibilities for Future Improvements (2)": In the
>> wish list for a kernel call to ask if the kernel runs UTC or TAI, a
>> couple of issues come to mind. First, many systems set the GPS
>> receiver to emit GPS System Time via NTP (and IRIG), so a GPS System
>> Time option may be needed.
>
> Yes.
>
> Though I would prefer using TAI instead of raw GPS time if a linear
> time scale is required. What if you use a different GNSS receiver,
> e.g. for Galileo, or the Chinese Beidou?
>
> GPS time (or whatever) is fine in closed projects/environments, but
> IMO a UTC and TAI are the "global" time scales, while GPS is specific
> to the U.S.
While TAI would be ideal for the reasons given, the problem is that TAI
is not yet widely supported enough.
>> Second, we often have the GPS (or PTP 1588)
>> receiver to emit GPS System Time, but never share this with downstream
>> servers, who are configured for UTC (but strangely the leap seconds
>> never come). The difference between UTC and GPS System Time is handled
>> in applications code. The reason for this approach is so that the bulk
>> of the system is free from step discontinuities, and only the
>> interfaces need deal with UTC.
>
> I agree, but as I've tried to point out above I think a better
> project design would have been to use TAI instead of GPS time. PTP
> works natively with TAI, and you can easily convert between he two
> scales.
>
> Of course it's easy to convert GPS to TAI, and vice versa, but you
> have to take care that more types of conversions are required and
> implemented correctly.
Right now, GPS System Time is the best solution. In ten years, I bet
the answer will be TAI.
> Thanks for your feedback!
Quite welcome.
Joe Gwinn
> Martin
> --
> Martin Burnicki
>
> MEINBERG Funkuhren GmbH & Co. KG
> Email: martin.burnicki at meinberg.de
> Phone: +49 (0)5281 9309-14
> Fax: +49 (0)5281 9309-30
>
> Lange Wand 9, 31812 Bad Pyrmont, Germany
> Amtsgericht Hannover 17HRA 100322
> Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
> Andre Hartmann, Heiko Gerstung
> Web: http://www.meinberg.de
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
From joegwinn at comcast.net Wed Mar 4 08:58:09 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Wed, 4 Mar 2015 08:58:09 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
References: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <20150304085809923436.3963f4a3@comcast.net>
On Tue, 03 Mar 2015 14:31:13 -0800, Hal Murray wrote:
>
>> GPS time (or whatever) is fine in closed projects/environments, but IMO a
>> UTC and TAI are the "global" time scales, while GPS is specific to
>> the U.S.
>
> Since GPS time is a fixed offset from TAI, it's easy to convert.
>
> My vote would be to use TAI rather than GPS wherever you are trying
> to avoid
> leap seconds.
>
> (If you are dealing with GPS itself rather than time in general, it might
> make sense to use GPS time consistently throughout a project.)
GPS System Time became embedded because it was what the available GPS
receivers supported (in addiction to UTC).
TAI would work as well, were it available in the day. It is just now
becoming available from GPS receivers - I saw TAI as a choice in a
Spectracom receiver, and assume that other makes do this as well.
The key issue is to use a timescale that is free of discontinuities.
Joe Gwinn
From sla at ucolick.org Wed Mar 4 09:56:40 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 4 Mar 2015 06:56:40 -0800
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150304085400160181.f241e70a@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
<20150304085400160181.f241e70a@comcast.net>
Message-ID: <20150304145640.GA26009@ucolick.org>
On Wed 2015-03-04T08:54:00 -0500, Joseph Gwinn hath writ:
> >> On Thu, 26 Feb 2015 15:09:01 +0100, Martin Burnicki wrote:
> > I think I'll give it a try soon. I'd expect that a negative leap
> > second might work if an appropriate announcement is received from a
> > refclock or upstream NTP server, but it will be interesting to find
> > out if this works with a NIST-style leap second file where the TAI
> > offset decreases at a given date.
>
> Hell - lots of code can't handle a positive leap second, so what hope
> is there?
There's a lot of hope for negative leap seconds to be inconsequential
to a lot of code.
An overloaded operating system which is timesharing may suspend a
process for a long time, so when that process wakes up it may find
that it has missed a second. A virtual machine running on a cloud
server farm in Oregon may be saved to disk, shipped across the
continent to North Carolina, and restarted over a second later -- or
kept on disk and replicated and restarted even later, multiple times.
What happens with a negative leap second is a lot like what happens to
non-real-time processes and machines as a routine part of operation.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From brooks at edlmax.com Wed Mar 4 10:18:01 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 04 Mar 2015 10:18:01 -0500
Subject: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
In-Reply-To: <20150304122854.IN2lDQnS%sdaoden@yandex.com>
References: <91FD778F6BE34B6798233E19A6BC246A@pc52>
<20150304122854.IN2lDQnS%sdaoden@yandex.com>
Message-ID: <54F72229.2080302@edlmax.com>
On 2015-03-04 07:28 AM, Steffen Nurpmeso wrote:
> "Tom Van Baak" wrote:
> |http://gpsworld.com/beidou-numbering-presents-leap-second-issue/
>
> Ok, but if engineers don't even get enough time from the business
> people to read manuals before they code the software then all bets
> are off. From a coders point of view 0-6 seems to be more logical
> than 1-7. (I personally, e.g., get more complex awk(1) coding
> almost always wrong in the first place because of base 1 not 0.)
Me too.
I remember reading somewhere that "Off-by-one errors" are by far the
most prevalent type of bug, no matter the language. There are lots of
variations of it :
Off-by-one error
http://en.wikipedia.org/wiki/Off-by-one_error
One not mentioned, and I see as closely related, is getting the *sign*
inverted. I've found that particularly easy to do in timekeeping code,
for example, applying the Leap Seconds or the initial 10s Leap Second
offset in the wrong direction at some point in the code. Everything can
look just fine until you finally compare it to some known reference to
discover you are off by 10 or the number of Leap Seconds, or something.
Programmers like zero-based because its more mathematically consistent,
but people generally don't like to label the first thing "zero". This
inconsistency is all over the place in society, and been a point of
contention in calendars and timekeeping for centuries.
Programmers have to be careful, duh. And timekeeping systems present a
particularly difficult testing challenge. Its doable, but you've got to
roll up your sleeves and do it. Those business people that might
allocate resources for the effort would hopefully recognize its not as
easy as looks.
Meantime, the "manual" is not easy to read, what with the specifications
scattered all over the place. Its really not rocket science when you get
to the bottom of it but it takes a long time to understand it.
-Brooks
>
> --steffen
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From brooks at edlmax.com Wed Mar 4 10:18:01 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 04 Mar 2015 10:18:01 -0500
Subject: [LEAPSECS] BeiDou Numbering Presents Leap-Second Issue
In-Reply-To: <20150304122854.IN2lDQnS%sdaoden@yandex.com>
References: <91FD778F6BE34B6798233E19A6BC246A@pc52>
<20150304122854.IN2lDQnS%sdaoden@yandex.com>
Message-ID: <54F72229.2080302@edlmax.com>
On 2015-03-04 07:28 AM, Steffen Nurpmeso wrote:
> "Tom Van Baak" wrote:
> |http://gpsworld.com/beidou-numbering-presents-leap-second-issue/
>
> Ok, but if engineers don't even get enough time from the business
> people to read manuals before they code the software then all bets
> are off. From a coders point of view 0-6 seems to be more logical
> than 1-7. (I personally, e.g., get more complex awk(1) coding
> almost always wrong in the first place because of base 1 not 0.)
Me too.
I remember reading somewhere that "Off-by-one errors" are by far the
most prevalent type of bug, no matter the language. There are lots of
variations of it :
Off-by-one error
http://en.wikipedia.org/wiki/Off-by-one_error
One not mentioned, and I see as closely related, is getting the *sign*
inverted. I've found that particularly easy to do in timekeeping code,
for example, applying the Leap Seconds or the initial 10s Leap Second
offset in the wrong direction at some point in the code. Everything can
look just fine until you finally compare it to some known reference to
discover you are off by 10 or the number of Leap Seconds, or something.
Programmers like zero-based because its more mathematically consistent,
but people generally don't like to label the first thing "zero". This
inconsistency is all over the place in society, and been a point of
contention in calendars and timekeeping for centuries.
Programmers have to be careful, duh. And timekeeping systems present a
particularly difficult testing challenge. Its doable, but you've got to
roll up your sleeves and do it. Those business people that might
allocate resources for the effort would hopefully recognize its not as
easy as looks.
Meantime, the "manual" is not easy to read, what with the specifications
scattered all over the place. Its really not rocket science when you get
to the bottom of it but it takes a long time to understand it.
-Brooks
>
> --steffen
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From sla at ucolick.org Wed Mar 4 22:05:31 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 4 Mar 2015 19:05:31 -0800
Subject: [LEAPSECS] a Japanese leap smear?
Message-ID: <20150305030531.GA4520@ucolick.org>
It looks like Kyushu Telecommunication network is considering its
own version of the leap smear
http://www.slideshare.net/apnic/the-leap-second-is-coming-by-tomonori-takada-apricot-2015
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From sla at ucolick.org Wed Mar 4 22:12:38 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 4 Mar 2015 19:12:38 -0800
Subject: [LEAPSECS] CPM15-2 at the end of the month
Message-ID: <20150305031237.GA4533@ucolick.org>
The second Conference Prepatory Meeting for ITU-R WRC 15 begins in
less than three weeks, and the deadline for contributions is Monday.
Some of delegations are still tweaking their documents, but the US
contributions are already listed at
http://www.itu.int/md/R12-CPM15.02-C/en
and they include one that wants to edit the current text for
Agenda Item 1.14.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From ghane0 at gmail.com Thu Mar 5 04:59:27 2015
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Thu, 5 Mar 2015 17:59:27 +0800
Subject: [LEAPSECS] a Japanese leap smear?
In-Reply-To: <20150305030531.GA4520@ucolick.org>
References: <20150305030531.GA4520@ucolick.org>
Message-ID:
On Thu, Mar 5, 2015 at 11:05 AM, Steve Allen wrote:
> It looks like Kyushu Telecommunication network is considering its
> own version of the leap smear
>
>
> http://www.slideshare.net/apnic/the-leap-second-is-coming-by-tomonori-takada-apricot-2015
>
The video of the talk is available on the APNIC channel on Youtube:
http://bit.ly/1w6hZbg
Starts at Minute 51.
--
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From martin.burnicki at meinberg.de Thu Mar 5 08:14:33 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:14:33 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150304085809923436.3963f4a3@comcast.net>
References: <20150303223113.C8DEB406057@ip-64-139-1-69.sjc.megapath.net>
<20150304085809923436.3963f4a3@comcast.net>
Message-ID: <54F856B9.8000503@meinberg.de>
Joseph Gwinn wrote:
> On Tue, 03 Mar 2015 14:31:13 -0800, Hal Murray wrote:
> TAI would work as well, were it available in the day. It is just now
> becoming available from GPS receivers - I saw TAI as a choice in a
> Spectracom receiver, and assume that other makes do this as well.
Meinberg receivers support this as well. ;-)
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Thu Mar 5 08:39:07 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:39:07 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To:
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
Message-ID: <54F85C7B.5050508@meinberg.de>
Tony Finch wrote:
> Martin Burnicki wrote:
>>
>> I agree, but as I've tried to point out above I think a better project design
>> would have been to use TAI instead of GPS time. PTP works natively with TAI,
>> and you can easily convert between he two scales.
>
> I don't understand this paragraph. The three timescales you mention have
> totally different formats:
>
> TAI: YYYY-MM-DD T HH:MM:SS
> PTP: SSSSSSSSSS
> GPS: WWWW SSSSSS
>
> They have different epochs:
>
> TAI: 1958-01-01 T 00:00:00 Z
> PTP: 1970-01-01 T 00:00:00 Z
> GPS: 1980-01-06 T 00:00:00 Z
>
> So I don't see how it makes sense to argue that PTP is more like TAI than
> GPS time.
In the strict scientific sense I agree.
However, in practice, and for "current" dates, you can convert each of
them to a number of seconds since the epoch, and for practical purposes
the difference is just an integral number of seconds.
For example, the IEEE Std 1588-2008 says:
"The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969
23:59:51.999918 UTC"
However, the time stamps used in the PTP packets are just binary numbers
of seconds, and you have to apply an integral number of seconds to
convert this to UTC.
Similarly, the comments in the NIST leap second file say:
# The second column shows the number of seconds that
# must be added to UTC to compute TAI for any timestamp
# at or after that epoch.
Even though the number of seconds between TAI and GPS timestamps is
constant, if you use all the scales TAI/GPS/UTC in an application you
have to do more different conversions than if you had only TAI and UTC.
Just imagine a PTP grandmaster, controlled by a GPS receiver which
outputs raw GPS time.
Tony, I'm sure you know all of the above, but I just wrote this to make
clear what I meant.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Thu Mar 5 08:42:23 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:42:23 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <6419860708DD473D85F53BD75EA8EDB4@pc52>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
<6419860708DD473D85F53BD75EA8EDB4@pc52>
Message-ID: <54F85D3F.1040001@meinberg.de>
Tom,
Tom Van Baak wrote:
>> GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm
>> not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has
>> no flag defined to announce a negative leap second, so there would be
>> major problems if one had to be inserted.
>
> Both WWVB and DCF-77 have a single leap second warning bit. With WWVB you look at the sign of DUT1 to know if the leap is insert or delete. So WWVB is fine.
Thanks for the hint.
> DCF-77 has no DUT1 or leap gender bit so, yes, there will be trouble. I'm sure PTB will figure something out if it ever comes to that.
Hm, the question is if existing receivers could handle what they figure
out, and I wonder if existing WWVB receivers check the sign of DUT1 to
determine if an upcoming leap second is +1 or -1.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Thu Mar 5 08:48:26 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:48:26 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F6B075.5010601@yahoo.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
<54F6B075.5010601@yahoo.com>
Message-ID: <54F85EAA.1060709@meinberg.de>
michael.deckers via LEAPSECS wrote:
>
> On 2015-03-03 21:05, Martin Burnicki wrote about
> negative leap seconds:
>
>> In the 7 year interval where no leap second was required/scheduled I
>> heard
>> several people saying we might have needed a negative leap second.
>
> Fortunately, this is not a matter of speculation.
I know.
> An easy way to
> see the trend of UT1 - UTC is to look at DUT1 (published in
> Bulletin D). DUT1 is an approximation to UT1 - UTC and has
> always stepped down (except, of course, at positive leap seconds),
> ever since the earliest Bulletin D available on the web (1991-06-20).
Yes, but if you observe that DUT1 steps down slower and slower you can
speculate whether it would start to step up over some years.
> Before a negative leap seconds would be scheduled, we would see
> DUT1 stepping up several times in a row, so there _is_ some
> advance warning.
Agreed.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Thu Mar 5 08:49:19 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:49:19 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F6CB36.6040502@edlmax.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<20150301171038516345.d9f27407@comcast.net> <54F62207.1070706@meinberg.de>
<54F6B075.5010601@yahoo.com> <54F6CB36.6040502@edlmax.com>
Message-ID: <54F85EDF.5080301@meinberg.de>
Brooks Harris wrote:
> We can't predict the future. It's fascinating to read about the many
> factors affecting Earth's rotation. It seems the largest one is the one
> we know least about - the Earth's core. I wonder what DUT1 would have
> looked like around the time of the Chicxulub impactor.
>
> Negative Leap Seconds have been a feature of the specification since the
> beginning. It gives a little more margin to accommodate the unknown, and
> it's not an onerous complication. I hope we concentrate on helping get
> implementations to conform to the UTC specs as they stand rather than
> look for justifications to over simplify the problem.
I totally agree.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From martin.burnicki at meinberg.de Thu Mar 5 08:55:58 2015
From: martin.burnicki at meinberg.de (Martin Burnicki)
Date: Thu, 05 Mar 2015 14:55:58 +0100
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150304085400160181.f241e70a@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<20150304085400160181.f241e70a@comcast.net>
Message-ID: <54F8606E.6030205@meinberg.de>
Joseph Gwinn wrote:
> On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
>> Now in 4.2.8 the leap second code has been reworked and cleaned up,
>> and a very quick look at the source code seems to indicate that this
>> might work again. At least there's code which passes the announcement
>> flag to the kernel, if kernel support is enabled.
>>
>> I think I'll give it a try soon. I'd expect that a negative leap
>> second might work if an appropriate announcement is received from a
>> refclock or upstream NTP server, but it will be interesting to find
>> out if this works with a NIST-style leap second file where the TAI
>> offset decreases at a given date.
>
> Hell - lots of code can't handle a positive leap second, so what hope
> is there?
Should we abandon everything which can't easily be handled, or where
developers don't work thoroughly?
> Right now, GPS System Time is the best solution. In ten years, I bet
> the answer will be TAI.
Agreed.
And we might already start to think about how to get this right in mixed
environments, e.g. using the NTF's General timestamp API, or find a way
to determine if the kernel time is UTC, or TAI.
Martin
--
Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Fax: +49 (0)5281 9309-30
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Gesch?ftsf?hrer/Managing Directors: G?nter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Web: http://www.meinberg.de
From brooks at edlmax.com Thu Mar 5 12:23:26 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Thu, 05 Mar 2015 12:23:26 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F85C7B.5050508@meinberg.de>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de>
Message-ID: <54F8910E.7040004@edlmax.com>
On 2015-03-05 08:39 AM, Martin Burnicki wrote:
> Tony Finch wrote:
>> Martin Burnicki wrote:
>>>
>>> I agree, but as I've tried to point out above I think a better
>>> project design
>>> would have been to use TAI instead of GPS time. PTP works natively
>>> with TAI,
>>> and you can easily convert between he two scales.
>>
>> I don't understand this paragraph. The three timescales you mention have
>> totally different formats:
>>
>> TAI: YYYY-MM-DD T HH:MM:SS
>> PTP: SSSSSSSSSS
>> GPS: WWWW SSSSSS
>>
>> They have different epochs:
>>
>> TAI: 1958-01-01 T 00:00:00 Z
>> PTP: 1970-01-01 T 00:00:00 Z
>> GPS: 1980-01-06 T 00:00:00 Z
>>
>> So I don't see how it makes sense to argue that PTP is more like TAI
>> than
>> GPS time.
>
> In the strict scientific sense I agree.
>
> However, in practice, and for "current" dates, you can convert each of
> them to a number of seconds since the epoch, and for practical
> purposes the difference is just an integral number of seconds.
I agree.
We have seen the casual term "TAI-like", meaning an "uninterrupted
incrementing count of seconds" from some epoch. PTP and GPS are
"TAI-like" in that sense.
>
> For example, the IEEE Std 1588-2008 says:
>
> "The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December
> 1969 23:59:51.999918 UTC"
>
> However, the time stamps used in the PTP packets are just binary
> numbers of seconds, and you have to apply an integral number of
> seconds to convert this to UTC.
Yes, that's how it must be treated.
I urge caution interpreting the meaning of the PTP Epoch as stated in
the spec.
The first part of that sentence is correct "The PTP epoch is 1 January
1970 00:00:00 TAI". But the second part, "which is 31 December 1969
23:59:51.999918 UTC", is not, or, is at least very misleading.
This of course begs the all questions regarding a "proleptic UTC"
timescale. What, exactly, is that? Did it exist before
1972-01-01T00:00:00Z (UTC)? Does it include the "rubber-band era"
between approximately 1961 and 1972?
The spec goes through long explanations of the relation of its epoch to
the "POSIX algorithm". It wanders through explanation of the
"rubber-band" era, and how the "broken down time" results are obtained
from gmtime(). This is all wicked confusing. Apparently the IEEE PTP
committee took "UTC" to include the "rubber-band era", and so attempted
to reconcile the PTP epoch to it.
In an *informative* Annex B - Timescales and epochs in PTP, there is
further (confusing) explanation, but then comes Table B.1?Relationships
between timescales. There we find -
Table B.1?Relationships between timescales
>From | To | Formula
NTP Seconds | PTP Seconds | PTP Seconds = NTP Seconds ? 2 208
988 800 + currentUtcOffset
PTP Seconds | NTP Seconds | NTP Seconds = PTP Seconds + 2 208
988 800 ? currentUtcOffset
GPS Seconds = | |
(GPS Weeks | |
? 7 ? 86 400) | |
+ GPSSecondsInLastWeek| |
(GPS week number must | |
include 1024 ? number | |
of rollovers) | PTP Seconds | PTP Seconds = GPS Seconds + 315
964 819
PTP Seconds | GPS Seconds | GPS Seconds = PTP Seconds ? 315
964 819
All the values in this table are *integral seconds* and they are correct
with respect to the definitions other timescale Epochs. (They neglect to
say the values for NTP are to NTP's "prime epoch of era 0", a subtle but
important point)
These are the values you must use for a practical implementation of PTP,
and that is the convention adopted by the PTP community. These values
*contradict* the second part of the epoch specification sentence
("...which is 31 December 1969 23:59:51.999918 UTC") and all the rest of
the PTP epoch explanations throughout the document.
The "rubber-band era", while historically important, is just not
relevant to practical timekeeping applications concerned with modern UTC
and "civil time". The scattered nature of the UTC specifications lead
from UTU-R Rec 460 to BIPM Annual Report on Time Activities Tables 1 and
2 that list the historical values of the "rubber-band era". This leads
to attempting to figure out what the historical values of UTC were
during this period. Its interesting, but its a huge distraction until
you realize it doesn't matter for most purposes. Like many of us, the
IEEE PTP committee fell into this trap.
You can construct a Gregorian calendar timescale that is proleptic to
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s
TAI/UTC offset) and treats the measurement unit as integral seconds.
This is, I believe, is the timescale most often used to calculate
offsets between timescales, but is never explicitly acknowledged or
named. Here I'll name it "Gregorian proleptic to UTC1972".
With that you can reconcile the offsets between the epochs of NTP, TAI,
PTP, POSIX, UTC, and GPS in integral seconds.
-----------------------------------------------------------------------------------------
Origin | UTC1972 | Coincides | UTC |Leap| TAI
Name | Seconds | with | |Secs|
| Offset | Origin of | ( Earth )
| | | (Correction)
| | | | |
-----------------------------------------------------------------------------------------
UTC1900 | -2272060800 | NTP | 1900-01-01T00:00:00Z | 10 |
1900-01-01 00:00:10
TAI1958 | -441763210 | TAI | 1957-12-31T23:59:50Z | 10 |
1958-01-01 00:00:00
TAI1970 | -63072010 | 1588/PTP | 1969-12-31T23:59:50Z | 10 |
1970-01-01 00:00:00
UTC1970 | -63072000 | POSIX | 1970-01-01T00:00:00Z | 10 |
1970-01-01 00:00:10
TAI1972 | -10 | UTC + 10s | 1971-12-31T23:59:50Z | 10 |
1972-01-01 00:00:00
UTC1972 | 0 | UTC | 1972-01-01T00:00:00Z | 10 |
1972-01-01 00:00:10
UTC1972_7_1 | +15724800 | First Leap | 1972-07-01T00:00:00Z | 11 |
1972-07-01 00:00:11
UTC1980_1_6 | +252892800 | GPS Epoch | 1980-01-06T00:00:00Z | 19 |
1980-01-06 00:00:19
On this timescale, for practical implementations, the PTP Epoch,
1970-01-01T00:00:00 (TAI) aligns with 1969-12-31T23:59:50 (Gregorian
proleptic to UTC1972), *not* 31 December 1969 23:59:51.999918 UTC.
-Brooks
>
> Similarly, the comments in the NIST leap second file say:
>
> # The second column shows the number of seconds that
> # must be added to UTC to compute TAI for any timestamp
> # at or after that epoch.
>
> Even though the number of seconds between TAI and GPS timestamps is
> constant, if you use all the scales TAI/GPS/UTC in an application you
> have to do more different conversions than if you had only TAI and UTC.
>
> Just imagine a PTP grandmaster, controlled by a GPS receiver which
> outputs raw GPS time.
>
> Tony, I'm sure you know all of the above, but I just wrote this to
> make clear what I meant.
>
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From zefram at fysh.org Thu Mar 5 13:29:57 2015
From: zefram at fysh.org (Zefram)
Date: Thu, 5 Mar 2015 18:29:57 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F8910E.7040004@edlmax.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
Message-ID: <20150305182957.GU8710@fysh.org>
Brooks Harris wrote:
>The first part of that sentence is correct "The PTP epoch is 1
>January 1970 00:00:00 TAI". But the second part, "which is 31
>December 1969 23:59:51.999918 UTC", is not, or, is at least very
>misleading.
It's correct to the microsecond precision given. My only real correctness
concern there is that it implies an exact equivalence which there isn't.
However, it is somewhat misleading by virtue of failing to explicate that
it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.
>Table B.1-Relationships between timescales
>From | To | Formula
>NTP Seconds | PTP Seconds | PTP Seconds = NTP Seconds - 2
>208 988 800 + currentUtcOffset
>PTP Seconds | NTP Seconds | NTP Seconds = PTP Seconds + 2
>208 988 800 - currentUtcOffset
...
>These are the values you must use for a practical implementation of
>PTP, and that is the convention adopted by the PTP community. These
>values *contradict* the second part of the epoch specification
>sentence
No, there is no contradiction there. The table makes no claim about
the correspondence between TAI and UTC at any particular point in time.
It makes correct claims about the correspondences between various scalar
representations of time. The only subtlety is the "currentUtcOffset" term
in the PTP<->NTP equations. The currentUtcOffset (meaning (TAI-UTC)/s)
is not defined for all points in time, and during the rubber-seconds
era of UTC it takes on non-integral values. This obviously can be a bit
confusing, because for the purposes of PTP as an operational protocol,
in which context only current timestamps are relevant, currentUtcOffset
is always well-defined and integral. For the purposes of table B.1 it
is not.
>You can construct a Gregorian calendar timescale that is proleptic to
>1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s
>TAI/UTC offset) and treats the measurement unit as integral seconds.
>This is, I believe, is the timescale most often used to calculate
I don't think you've succeeded in defining a particular time scale here.
Your previous messages, and the table and comments later in your present
message, suggest that you're thinking of a time scale that amounts to TAI
- 10 s prior to 1972. But the phrases "Gregorian calendar timescale"
and "treats the measurement unit as integral seconds" don't seem to
actually imply that. I can't make much sense of either phrase.
>With that you can reconcile the offsets between the epochs of NTP,
>TAI, PTP, POSIX, UTC, and GPS in integral seconds.
Your focus on epochs is unhealthy. Some of the epochs don't unambiguously
correspond to particular points in time, and in context that's not
a problem. Notice that table B.1 that you quoted doesn't make any
reference to epochs per se: it doesn't describe relationships between
epochs, it describes relationships between *scalar values*. What matters
is that these scalar values correspond to specific points in time over the
time period that matters for the application. Scalar value zero isn't
inherently part of the relevant time period. Taking NTP in particular,
no one was running NTP in 1900, so it is of no significance that NTP
zero doesn't correspond to a specific point in time.
-zefram
From joegwinn at comcast.net Thu Mar 5 20:30:58 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Thu, 5 Mar 2015 20:30:58 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F8606E.6030205@meinberg.de>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<20150304085400160181.f241e70a@comcast.net> <54F8606E.6030205@meinberg.de>
Message-ID: <20150305203058926712.92aee470@comcast.net>
On Thu, 05 Mar 2015 14:55:58 +0100, Martin Burnicki wrote:
> Joseph Gwinn wrote:
>> On Tue, 03 Mar 2015 21:56:42 +0100, Martin Burnicki wrote:
>>> Now in 4.2.8 the leap second code has been reworked and cleaned up,
>>> and a very quick look at the source code seems to indicate that this
>>> might work again. At least there's code which passes the announcement
>>> flag to the kernel, if kernel support is enabled.
>>>
>>> I think I'll give it a try soon. I'd expect that a negative leap
>>> second might work if an appropriate announcement is received from a
>>> refclock or upstream NTP server, but it will be interesting to find
>>> out if this works with a NIST-style leap second file where the TAI
>>> offset decreases at a given date.
>>
>> Hell - lots of code can't handle a positive leap second, so what hope
>> is there?
>
> Should we abandon everything which can't easily be handled, or where
> developers don't work thoroughly?
Nahh. I'm just saying don't get your hopes up.
>> Right now, GPS System Time is the best solution. In ten years, I bet
>> the answer will be TAI.
>
> Agreed.
>
> And we might already start to think about how to get this right in
> mixed environments, e.g. using the NTF's General timestamp API, or
> find a way to determine if the kernel time is UTC, or TAI.
Yes. My experience is that it can be hard to get the time community to
agree on an approach, especially if the community must convince
non-time communities (like POSIX) to implement something perfect but
very complex, especially if it doesn't solve a problem important to
non-time folk.
Joe Gwinn
From imp at bsdimp.com Thu Mar 5 20:52:41 2015
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 5 Mar 2015 18:52:41 -0700
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150305203058926712.92aee470@comcast.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<20150304085400160181.f241e70a@comcast.net> <54F8606E.6030205@meinberg.de>
<20150305203058926712.92aee470@comcast.net>
Message-ID:
> On Mar 5, 2015, at 6:30 PM, Joseph Gwinn wrote:
>
> On Thu, 05 Mar 2015 14:55:58 +0100, Martin Burnicki wrote:
>>
>> And we might already start to think about how to get this right in
>> mixed environments, e.g. using the NTF's General timestamp API, or
>> find a way to determine if the kernel time is UTC, or TAI.
>
> Yes. My experience is that it can be hard to get the time community to
> agree on an approach, especially if the community must convince
> non-time communities (like POSIX) to implement something perfect but
> very complex, especially if it doesn't solve a problem important to
> non-time folk.
The big problem with leap seconds are they are just a second. Nobody cares
enough about a second to give it more than a passing thought. This is why
so many things implement / spec leap seconds so poorly that bugs abound.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From brooks at edlmax.com Fri Mar 6 14:04:44 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Fri, 06 Mar 2015 14:04:44 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150305182957.GU8710@fysh.org>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org>
Message-ID: <54F9FA4C.7060805@edlmax.com>
Hi Zefram,
>> Your focus on epochs is unhealthy.
I don't claim to be any more healthy than the many other folks I've had
these discussions with, most of whom are *obsessed* with, and *insistent
upon*, specifying a known *immovable* epoch.
I think I could characterize your focus on using "scalar values" as a
bit unhinged. :-)
The difference in our thinking seems to be my objective of placing the
various timescale epochs at fixed offsets from 1972-01-01T00:00:00Z
(UTC) = 1972-01-01T00:00:10Z (TAI) v.s. yours that allows the epochs to
slip with each Leap Second in the manner NTP and POSIX do, which is, as
you call it, "scalar".
Indeed, I think one of the reasons many people feel the need to use a
"TAI-like" timescale is that generally those timescale's epochs are
*fixed*, whereas with the NTP and POSIX implementations of "UTC-like"
timescales, the epochs *slip*, essentially creating a new timescale with
a different epoch offset to 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10Z (TAI) with each Leap Second.
I've actually tried to answer your earlier emails but each time it's
turned to a multi-page essay and I never quite completed it. I'll try to
finish that, but here I'll try to quickly answer your comments.
On 2015-03-05 01:29 PM, Zefram wrote:
> Brooks Harris wrote:
>> The first part of that sentence is correct "The PTP epoch is 1
>> January 1970 00:00:00 TAI". But the second part, "which is 31
>> December 1969 23:59:51.999918 UTC", is not, or, is at least very
>> misleading.
> It's correct to the microsecond precision given. My only real correctness
> concern there is that it implies an exact equivalence which there isn't.
> However, it is somewhat misleading by virtue of failing to explicate that
> it is using the rubber-seconds UTC which is otherwise irrelevant to PTP.
Yes, it is "otherwise irrelevant to PTP". Thats my point. All the
discussion about the rubber-band period and use of "the POSIX algoritm"
is beside the point for practical implementation, and hence, only a
misleading distraction.
>
>> Table B.1-Relationships between timescales
> >From | To | Formula
>> NTP Seconds | PTP Seconds | PTP Seconds = NTP Seconds - 2
>> 208 988 800 + currentUtcOffset
>> PTP Seconds | NTP Seconds | NTP Seconds = PTP Seconds + 2
>> 208 988 800 - currentUtcOffset
> ...
>> These are the values you must use for a practical implementation of
>> PTP, and that is the convention adopted by the PTP community. These
>> values *contradict* the second part of the epoch specification
>> sentence
> No, there is no contradiction there. The table makes no claim about
> the correspondence between TAI and UTC at any particular point in time.
It does if your objective is to link PTP time to the fixed epoch of
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI), to the NTP prime
epoch of era 0, and to the POSIX "the Epoch".
It can *also* be interpreted as scalar offsets, as you are interpreting
them, yes, if that's how you need to use them.
> It makes correct claims about the correspondences between various scalar
> representations of time. The only subtlety is the "currentUtcOffset" term
> in the PTP<->NTP equations. The currentUtcOffset (meaning (TAI-UTC)/s)
> is not defined for all points in time, and during the rubber-seconds
> era of UTC it takes on non-integral values.
Not in a practical timescale implementation. The "rubber-band era" is
just entirely irrelevant. Its historically interesting, and may be
required for some special application concerning that period, but for
practical "UTC-like" timekeeping its just an historical curiosity.
This fact is somewhat more apparent looking at the IERS publication
Leap_Second_History.dat, at
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
see *no values* before "1 1 1972" - the "rubber-band era" is gone.
That's correct - the "rubber band era" no long exists.
[By the way, I think this document is the most well formed information
about TAI/UTC. By using MJD there is no mistaking on what day each Leap
Second occurs. I haven't found any official information at IERS about
the policies of this document's publication but I think this may be the
best source of official Leap Second information available. Note it
includes the upcoming 2015-07-01 Leap Second.]
In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset =
10s.
PTP time does not exist before this date-time. Official TAI exists from
the origin of 1958-01-01T00:00:00 (TAI). "Integral second UTC" didn't
exist before 1972-01-01T00:00:00Z (UTC). Thats where you need a
timescale that is an integral second measure proleptic to
1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain. With
that, the PTP epoch is 1970-01-01T00:00:00 (TAI) = 1969-12-31T23:59:50Z
(UTC).
By the way, I think its unfortunate they didn't specify the epoch as
"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would
coincide exactly with POSIX "the Epoch". As it is there's a 10s
difference between them. Thus, more complexity and potentially more
confusion.
> This obviously can be a bit
> confusing, because for the purposes of PTP as an operational protocol,
> in which context only current timestamps are relevant, currentUtcOffset
> is always well-defined and integral.
Yes.
> For the purposes of table B.1 it
> is not.
I think you mean if you are attempting to map into the "rubber-band era"
you could interpret the currentUtcOffset value to be non-integral, but
that's not explicit in the table. In fact I see currentUtcOffset as
being defined as integral seconds. In any event, any consideration of
the "rubber-band era" is just not relevant, as above.
>
>> You can construct a Gregorian calendar timescale that is proleptic to
>> 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s
>> TAI/UTC offset) and treats the measurement unit as integral seconds.
>> This is, I believe, is the timescale most often used to calculate
> I don't think you've succeeded in defining a particular time scale here.
> Your previous messages, and the table and comments later in your present
> message, suggest that you're thinking of a time scale that amounts to TAI
> - 10 s prior to 1972. But the phrases "Gregorian calendar timescale"
> and "treats the measurement unit as integral seconds" don't seem to
> actually imply that. I can't make much sense of either phrase.
I'm going to need to work on this explanation some more, which I'll try
to do, but I need to get this respond off my desk. Perhaps part of
understanding what I'm saying is clarified in the topic of "fixed epoch"
v.s. "scalar".
>
>> With that you can reconcile the offsets between the epochs of NTP,
>> TAI, PTP, POSIX, UTC, and GPS in integral seconds.
> Your focus on epochs is unhealthy.
I could say, for purposes of precision timekeeping, it is unhealthy to
focus on "scalar values" - "fixed epoch" is more appropriate. Hence my
joke about calling you unhinged :-)
> Some of the epochs don't unambiguously
> correspond to particular points in time, and in context that's not
> a problem.
I'd say it *is* a problem. I think you mean "in context" of mapping to
conventional timekeeping mechanisms like NTP and POSIX. It is true in
those "the epochs don't unambiguously correspond to particular points in
time". But that's exactly the issue I'm trying to point out - everything
is slipping around in many conventional timekeeping systems.
> Notice that table B.1 that you quoted doesn't make any
> reference to epochs per se: it doesn't describe relationships between
> epochs,
I think it does.
"NTP Seconds = PTP Seconds + 2 208 988 800 ? currentUtcOffset" describes
the absolute seconds offset from the NTP prime epoch era 0 to the PTP
Epoch. If your implementation is to keep those reference points fixed,
that tells you the constant offset.
> it describes relationships between *scalar values*.
That too, if that's your need and how you treat those values.
> What matters
> is that these scalar values correspond to specific points in time over the
> time period that matters for the application. Scalar value zero isn't
> inherently part of the relevant time period. Taking NTP in particular,
> no one was running NTP in 1900, so it is of no significance that NTP
> zero doesn't correspond to a specific point in time.
I think that is exactly at the root of the entire difficulty with the
"Leap Seconds" conversation. We understand both NTP and POSIX are flawed
with respect to Leap Seconds and UTC because their counting mechanisms
cannot count to 23:59:60. Thus, each Leap Second *slips the epoch*, so
"seconds from the epoch" is always the number of "Leap Seconds in
effect" short, in essence creating many separate timescales.
>> no one was running NTP in 1900,
Of course not. But its conceptual timescale is in use everywhere.
I have constructed an implementation of an experimental reference
timescale with fixed epoch offsets starting at 1900-01-01T00:00:00Z
(UTC) = 1900-01-01T00:00:10 (TAI). This spans all the interesting epochs
- NTP, TAI, PTP, POSIX, UTC, and GPS. I can map this to correct
representations on any of those timescales (of course NTP and POSIX
repeat or over-count the Leap Seconds), and confirmed this with
reference to Windows Systemtime, the MSVC implementation of POSIX time_t
etc, and verified against an implementation of SNTP. To do this you need
a complete Leap Seconds table, of course. Having an official method of
obtaining those values automatically is a big missing peice of the UTC
specs in general, and the subject of other threads on the LEAPSECS list.
The counting mechanisms of NTP and POSIX are ubiquitous in OSs, systems,
and languages. So, the thought process about UTC and Leap Seconds is
understandably focused on resolving the differences between NTP/POSIX
and proper UTC. That, I think, is where your "scalar" mapping point of
view comes from. And I agree, that approach is necessary to map UTC to
NTP and POSIX.
But fundamentally, NTP and POSIX *cannot possibly work correctly* where
proper UTC is concerned because the 23:59:60 count just goes missing.
Yes, it can be made to work for most date-times if you're careful -
that's whats going on today. But it can't represent the Leap Second
itself (23:59:60 and potentially the rollover at 23:59:58), so its
counting mechanism is basically *incomplete* and durations are
ambiguous. That's not "precision timekeeping". The insertion of Leap
Seconds upsets the apple cart because it introduces complexity, and in
some cases confusion, into the implementations, and so, potentially, *bugs*.
I'm sure you'll give me a chance to further explain myself and my
unhealthy views :-)
-Brooks
>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From cfuhb-acdgw at earthlink.net Fri Mar 6 20:30:14 2015
From: cfuhb-acdgw at earthlink.net (Paul Hirose)
Date: Fri, 06 Mar 2015 17:30:14 -0800
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F9FA4C.7060805@edlmax.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
Message-ID: <54FA54A6.20408@earthlink.net>
On 2015-03-06 11:04, Brooks Harris wrote:
> The "rubber-band era" is
> just entirely irrelevant. Its historically interesting, and may be
> required for some special application concerning that period, but for
> practical "UTC-like" timekeeping its just an historical curiosity.
>
> This fact is somewhat more apparent looking at the IERS publication
> Leap_Second_History.dat, at
> https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
> see *no values* before "1 1 1972" - the "rubber-band era" is gone.
> That's correct - the "rubber band era" no long exists.
Since the name of the document is "leap second history", the rate
offsets and fractional second step adjustments before 1972 aren't
applicable. They can be found elsewhere at the IERS site:
http://hpiers.obspm.fr/eop-pc/index.php?index=UTC&lang=en
I distribute a Windows astronomical toolbox DLL which includes time
scale conversions. Since astronomy often requires analysis of old data,
the DLL can deal with pre-1972 UTC. I won't get into the dispute over
whether or not that's bona fide UTC! However, the IERS and USNO
recognize it as such, so I assume the user will expect time conversions
to work in that era. (I have never needed that capability myself.)
From stenn at ntp.org Fri Mar 6 21:02:12 2015
From: stenn at ntp.org (Harlan Stenn)
Date: Sat, 07 Mar 2015 02:02:12 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: Paul Hirose's (cfuhb-acdgw@earthlink.net) message
dated Fri, 06 Mar 2015 17:30:14. <54FA54A6.20408@earthlink.net>
Message-ID:
Paul,
Paul Hirose writes:
> I distribute a Windows astronomical toolbox DLL which includes time
> scale conversions. Since astronomy often requires analysis of old
> data, the DLL can deal with pre-1972 UTC. I won't get into the dispute
> over whether or not that's bona fide UTC! However, the IERS and USNO
> recognize it as such, so I assume the user will expect time
> conversions to work in that era. (I have never needed that capability
> myself.)
When we get a bit more down the road with NTF's General Timestamp API,
I'd appreciate your taking a look at what we're doing and helping out in
any way you are up for. One of the issues that will need more attention
is pre-1972 stuff.
--
Harlan Stenn
http://networktimefoundation.org - be a member!
From sla at ucolick.org Fri Mar 6 21:57:01 2015
From: sla at ucolick.org (Steve Allen)
Date: Fri, 6 Mar 2015 18:57:01 -0800
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To:
References: <54FA54A6.20408@earthlink.net>
Message-ID: <20150307025701.GA11888@ucolick.org>
On Sat 2015-03-07T02:02:12 +0000, Harlan Stenn hath writ:
> When we get a bit more down the road with NTF's General Timestamp API,
> I'd appreciate your taking a look at what we're doing and helping out in
> any way you are up for. One of the issues that will need more attention
> is pre-1972 stuff.
Before 1972 is pretty simple.
Without some means of comparing an event with a particular radio
broadcast time signal or a particular astronomical event, everything
before 1972 is just plain UT or GMT back to 1676, and UT before that.
Any subsecond deviations from what those represent (including worries
about UT0, UT1, UT2) are only available by painstaking inspection (and
re-interpretation into modern terminology) of the tabulations in BIH
Bulletin Horaire.
Of course I'm ignoring any timezones. That's a whole 'nother layer
of painstaking historical investigation for any given locale.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From imp at bsdimp.com Fri Mar 6 23:37:42 2015
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 6 Mar 2015 21:37:42 -0700
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150307025701.GA11888@ucolick.org>
References: <54FA54A6.20408@earthlink.net>
<20150307025701.GA11888@ucolick.org>
Message-ID: <2032DD98-1F64-426C-9A14-7030312511D4@bsdimp.com>
> On Mar 6, 2015, at 7:57 PM, Steve Allen wrote:
>
> On Sat 2015-03-07T02:02:12 +0000, Harlan Stenn hath writ:
>> When we get a bit more down the road with NTF's General Timestamp API,
>> I'd appreciate your taking a look at what we're doing and helping out in
>> any way you are up for. One of the issues that will need more attention
>> is pre-1972 stuff.
>
> Before 1972 is pretty simple.
>
> Without some means of comparing an event with a particular radio
> broadcast time signal or a particular astronomical event, everything
> before 1972 is just plain UT or GMT back to 1676, and UT before that.
Before 1972 there were radio signals. LORAN C was operated from the early
60?s onward, and many receivers existed to recover timing data from them.
WWV dates back to the 30?s, with the current Ft Collins transmitter dating from
the 1960?s. It started broadcasting UTC time in December 1968.
> Any subsecond deviations from what those represent (including worries
> about UT0, UT1, UT2) are only available by painstaking inspection (and
> re-interpretation into modern terminology) of the tabulations in BIH
> Bulletin Horaire.
I?m not entirely sure that?s correct. You can recover time to at least tens
of microseconds from WWV or LORAN-C, which is quite a bit better than
you need to notice the difference between UTC and UT1. With a good cesium
standard, synchronized at NBS, running off battery power for the car ride to the
lab, WWV could keep you on frequency as well, and you could get sub-microsecond
level of performance. I got to hear many tales of the old days when they did
this sort of two-way time exchange before satellites. This allowed the frequency
broadcast by WWV to be within a few parts in e11 (day it is 100x better).
If you read the histories of WWV, they talk about the close proximity to Boulder
enabling this. The reason was that the battery backup would be enough to last
the 45 minutes or so it takes to go from Boulder to Fort Collins? WWV followed
the frequency offset + phase steps in the rubber leap second era, which was
an attempt to keep UT1 and UTC not only synchronized, but also syntonized. I find
it curious that the practice of adjusting the frequency of the clocks persisted for
5 years after the SI second was defined.
So it isn?t outside the realm of possibilities that you?d have people making measurements
from the late 60?s till 1972 using UTC (and yes, it did exist in a practical form
before 1972, just not in the current form and the common usage often leaves some
ambiguity between the actual, realized form as broadcast by WWV, or the proleptic
form w/o leap seconds). Actual measurements from this time, though, were based
on something approaching the UTC as broadcast by WWV. Not sure how many data
sets from that time survive until today, and how many need to be converted from that
to UT1 or UT2, but evidentially there?s some...
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From sla at ucolick.org Fri Mar 6 23:57:17 2015
From: sla at ucolick.org (Steve Allen)
Date: Fri, 6 Mar 2015 20:57:17 -0800
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <2032DD98-1F64-426C-9A14-7030312511D4@bsdimp.com>
References: <54FA54A6.20408@earthlink.net>
<20150307025701.GA11888@ucolick.org>
<2032DD98-1F64-426C-9A14-7030312511D4@bsdimp.com>
Message-ID: <20150307045717.GA12991@ucolick.org>
On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ:
> So it isn't outside the realm of possibilities that you'd have people making measurements
> from the late 60's till 1972 using UTC (and yes, it did exist in a practical form
> before 1972, just not in the current form and the common usage often leaves some
> ambiguity between the actual, realized form as broadcast by WWV, or the proleptic
> form w/o leap seconds). Actual measurements from this time, though, were based
> on something approaching the UTC as broadcast by WWV. Not sure how many data
> sets from that time survive until today, and how many need to be converted from that
> to UT1 or UT2, but evidentially there's some...
Yes and yes, but these are specialty applications for specialty datasets
which can only be reduced to a precise modern time scale if the original
observations and equipment were meticulously calibrated.
And then they must be reduced by going back to look at, e.g.
https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361
Please don't try to make this part of a General Timestamp API.
Before 1972, for a general API, there is just UT.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From imp at bsdimp.com Sat Mar 7 00:19:11 2015
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 6 Mar 2015 22:19:11 -0700
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150307045717.GA12991@ucolick.org>
References: <54FA54A6.20408@earthlink.net>
<20150307025701.GA11888@ucolick.org>
<2032DD98-1F64-426C-9A14-7030312511D4@bsdimp.com>
<20150307045717.GA12991@ucolick.org>
Message-ID: <2078B80E-6BC8-47AB-82E1-F241ADB7E8D4@bsdimp.com>
> On Mar 6, 2015, at 9:57 PM, Steve Allen wrote:
>
> On Fri 2015-03-06T21:37:42 -0700, Warner Losh hath writ:
>> So it isn't outside the realm of possibilities that you'd have people making measurements
>> from the late 60's till 1972 using UTC (and yes, it did exist in a practical form
>> before 1972, just not in the current form and the common usage often leaves some
>> ambiguity between the actual, realized form as broadcast by WWV, or the proleptic
>> form w/o leap seconds). Actual measurements from this time, though, were based
>> on something approaching the UTC as broadcast by WWV. Not sure how many data
>> sets from that time survive until today, and how many need to be converted from that
>> to UT1 or UT2, but evidentially there's some...
>
> Yes and yes, but these are specialty applications for specialty datasets
> which can only be reduced to a precise modern time scale if the original
> observations and equipment were meticulously calibrated.
> And then they must be reduced by going back to look at, e.g.
> https://plus.google.com/photos/112320138481375234766/albums/6078225731350227361
There are a few observatories around here (being in proximity to Boulder) that have
data from this time. They know it is only good to a millisecond or so, but that?s UTC
not UT. They don?t have to recreate the calibrations or whatever today because they
know the data isn?t much better than that. Still, there is some of it that it matters to. Though
maybe by now the old professors are gone and the data is too? My data on this is
about 15 years old, and even then it was second hand...
> Please don't try to make this part of a General Timestamp API.
>
> Before 1972, for a general API, there is just UT.
Generally yes. I agree. For most data, UT is close enough, since that also required a lot
of specialty data that you have to look up in books if you want to covert it to elapsed time.
I?d make it be opt-in, but I wouldn?t make it impossible.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From ashtongj at comcast.net Sat Mar 7 08:10:27 2015
From: ashtongj at comcast.net (G Ashton)
Date: Sat, 7 Mar 2015 08:10:27 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <2078B80E-6BC8-47AB-82E1-F241ADB7E8D4@bsdimp.com>
References: <54FA54A6.20408@earthlink.net>
<20150307025701.GA11888@ucolick.org>
<2032DD98-1F64-426C-9A14-7030312511D4@bsdimp.com>
<20150307045717.GA12991@ucolick.org>
<2078B80E-6BC8-47AB-82E1-F241ADB7E8D4@bsdimp.com>
Message-ID: <001801d058d8$153f8910$3fbe9b30$@comcast.net>
A general API that deals with old dates should allow for the possibility the original observation was stated in apparent solar time. Or, an explicit warning should be provided that the authors of the API believed that for the intended applications, given the limited accuracy of local time standards and watches, the difference between mean and solar time is not considered important.
From brooks at edlmax.com Sat Mar 7 11:49:31 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sat, 07 Mar 2015 11:49:31 -0500
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54FA54A6.20408@earthlink.net>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
<54FA54A6.20408@earthlink.net>
Message-ID: <54FB2C1B.90006@edlmax.com>
On 2015-03-06 08:30 PM, Paul Hirose wrote:
> On 2015-03-06 11:04, Brooks Harris wrote:
>> The "rubber-band era" is
>> just entirely irrelevant. Its historically interesting, and may be
>> required for some special application concerning that period, but for
>> practical "UTC-like" timekeeping its just an historical curiosity.
>>
>> This fact is somewhat more apparent looking at the IERS publication
>> Leap_Second_History.dat, at
>> https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat. There we
>> see *no values* before "1 1 1972" - the "rubber-band era" is gone.
>> That's correct - the "rubber band era" no long exists.
>
> Since the name of the document is "leap second history", the rate
> offsets and fractional second step adjustments before 1972 aren't
> applicable. They can be found elsewhere at the IERS site:
>
> http://hpiers.obspm.fr/eop-pc/index.php?index=UTC&lang=en
>
> I distribute a Windows astronomical toolbox DLL which includes time
> scale conversions. Since astronomy often requires analysis of old
> data, the DLL can deal with pre-1972 UTC. I won't get into the dispute
> over whether or not that's bona fide UTC! However, the IERS and USNO
> recognize it as such, so I assume the user will expect time
> conversions to work in that era. (I have never needed that capability
> myself.)
Of course its important the purpose of any timescale be stated
carefully, and I haven't done that in what I wrote in the email
containing this paragraph. In the company of the astronomers here on the
list I might have been a bit insensitive to lump their objectives into
"some special application".
The challenge I'm trying to solve is to provide a deterministic
timekeeping and labeling scheme for date and time *after*
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10 (TAI). This is
essentially the purpose of "civil time" timekeeping as is typically
intended. The timescale I've attempted to describe is intended to be
single reference timescale with a *fixed epoch* at the NTP prime epoch
era 0. (Conceptually this could be extended into the indefinite past.)
The timescale before 1972 is an abstract proleptic Gregorian calendar
scale for purposes of calculation convenience. On this scale, like NTP,
PTP, and POSIX, any date-time before 1972-01-01T00:00:00Z (UTC) is
considered either inaccurate or invalid.
It is in that sense, and with regard to that purpose, I said "The
"rubber-band era" is just entirely irrelevant.".
-Brooks
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From ashtongj at comcast.net Sat Mar 7 12:04:38 2015
From: ashtongj at comcast.net (G Ashton)
Date: Sat, 7 Mar 2015 12:04:38 -0500
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
Message-ID: <000001d058f8$cdb74c60$6925e520$@comcast.net>
Brooks Harris wrote on Saturday, March 7, 2015 11:50 :
.
.
"The challenge I'm trying to solve is to provide a deterministic timekeeping
and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10 (TAI). This is essentially the purpose of "civil time"
timekeeping as is typically intended....The timescale before 1972 is an
abstract proleptic Gregorian calendar scale for purposes of calculation
convenience. On this scale, like NTP, PTP, and POSIX, any date-time before
1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid."
Civil timekeeping is concerned with many things, including determining when
one date ends and another begins. Thus civil timekeeping is inextricably
linked to civil calendars. Although the time of day of past events become
less and less important as the decades pass, the date of those events remain
important. Since some computer applications routinely attempt, in their
clumsy way, to account for timezones, timekeeping is potentially important
for the computer representation of timestamps, even when the humans using
the computer are only interested in the date. Of course, dates long before
1972 are of interest in civil matters; dates of birth immediately come to
mind. So when Brooks Harris presents his API to his stakeholders, I think a
more thorough explanation of why date-time expressions before 1972 will be "
considered either inaccurate or invalid" will be needed.
Gerard Ashton
From brooks at edlmax.com Sat Mar 7 14:14:07 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sat, 07 Mar 2015 14:14:07 -0500
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <000001d058f8$cdb74c60$6925e520$@comcast.net>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
Message-ID: <54FB4DFF.3010106@edlmax.com>
Hi Gerard,
On 2015-03-07 12:04 PM, G Ashton wrote:
>
> Brooks Harris wrote on Saturday, March 7, 2015 11:50 :
> .
> .
> "The challenge I'm trying to solve is to provide a deterministic timekeeping
> and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) =
> 1972-01-01T00:00:10 (TAI). This is essentially the purpose of "civil time"
> timekeeping as is typically intended....The timescale before 1972 is an
> abstract proleptic Gregorian calendar scale for purposes of calculation
> convenience. On this scale, like NTP, PTP, and POSIX, any date-time before
> 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid."
>
> Civil timekeeping is concerned with many things, including determining when
> one date ends and another begins. Thus civil timekeeping is inextricably
> linked to civil calendars. Although the time of day of past events become
> less and less important as the decades pass, the date of those events remain
> important. Since some computer applications routinely attempt, in their
> clumsy way, to account for timezones, timekeeping is potentially important
> for the computer representation of timestamps, even when the humans using
> the computer are only interested in the date. Of course, dates long before
> 1972 are of interest in civil matters; dates of birth immediately come to
> mind.
I agree.
> So when Brooks Harris presents his API to his stakeholders, I think a
> more thorough explanation of why date-time expressions before 1972 will be "
> considered either inaccurate or invalid" will be needed.
It is typically warned that date and time before 1972 cannot be
accurately represented with NTP or POSIX, for examples. These
timescale's origins precede 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10 (TAI) and seek to represent date-time counting
*forward*. They give no consideration to date-time accuracy before 1972,
but operate on proleptic scales convenient for computation. This is
generally true with widely available timekeeping services on OSs,
systems, languages, and many typical applications because so many of
them implement mechanisms based on the heritage of the POSIX timekeeping
mechanisms, complete with its flaws with respect to representing UTC and
Leap Seconds.
In the discussions I've been involved with many people argued
strenuously "we don't care about the past, only accurate date-time going
forward!". The reason I'm choosing to ignore the subject of accurate
date-times before 1972 is not that its not important, but probably the
same reason its side-stepped by NTP, PTP, POSIX, and GPS - its just too
expansive a topic to tackle in some commonly accepted way. For date-time
before 1972 you've got to switch to some other timescale depending on
the purpose at hand.
-Brooks
>
> Gerard Ashton
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From sla at ucolick.org Sat Mar 7 15:01:12 2015
From: sla at ucolick.org (Steve Allen)
Date: Sat, 7 Mar 2015 12:01:12 -0800
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FB4DFF.3010106@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com>
Message-ID: <20150307200111.GA24366@ucolick.org>
On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ:
> It is typically warned that date and time before 1972 cannot be
> accurately represented with NTP or POSIX, for examples.
I would say that for PTP
* all seconds are always SI seconds
* seconds after 1972-01-01 correspond to (TAI - 10)
* seconds before 1972-01-01 do not align with civil time
* in particular, 1970-01-01 in PTP does not correspond to
any event in any time scale which was then in use,
but that does not matter
For PTP it is the uniformity going forward that is the goal.
I would say that the intent NTP and POSIX is to correspond to civil
time in contemporary use. Therefore, for dates before 1972-01-01
NTP and POSIX are counting seconds of UT.
For dates after 1972-01-01 I would say that NTP and POSIX are both
confused about whether they are counting SI seconds or UT days.
Therein, of course, lies the basis of this LEAPSECS list.
I see it as inevitable that the confusion must end, therefore NTP and
POSIX will eventually be unambiguous that they are counting SI
seconds. That means that, eventually, any general purpose time scale
intended to correspond to civil time will be a piecewise continuous
time scale. Such general purpose time scales will have a date at
which they switch from counting UT days to counting SI seconds.
Deciding on that date, and how it will be implemented and understood,
is what we hope the ITU-R will accomplish at WRC-15.
> For date-time before 1972 you've got to switch to some
> other timescale depending on the purpose at hand.
Exactly so. Before 1972 civil time was not SI seconds.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From joegwinn at comcast.net Sat Mar 7 18:50:40 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Sat, 7 Mar 2015 18:50:40 -0500
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FB4DFF.3010106@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com>
Message-ID: <20150307185040843495.de5a6666@comcast.net>
On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
> Hi Gerard,
>
> On 2015-03-07 12:04 PM, G Ashton wrote:
>>
>> Brooks Harris wrote on Saturday, March 7, 2015 11:50 :
>> .
>> .
>> "The challenge I'm trying to solve is to provide a deterministic
>> timekeeping
>> and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) =
>> 1972-01-01T00:00:10 (TAI). This is essentially the purpose of "civil time"
>> timekeeping as is typically intended....The timescale before 1972 is an
>> abstract proleptic Gregorian calendar scale for purposes of calculation
>> convenience. On this scale, like NTP, PTP, and POSIX, any date-time before
>> 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid."
>>
>> Civil timekeeping is concerned with many things, including determining when
>> one date ends and another begins. Thus civil timekeeping is inextricably
>> linked to civil calendars. Although the time of day of past events become
>> less and less important as the decades pass, the date of those
>> events remain
>> important. Since some computer applications routinely attempt, in their
>> clumsy way, to account for timezones, timekeeping is potentially important
>> for the computer representation of timestamps, even when the humans using
>> the computer are only interested in the date. Of course, dates long before
>> 1972 are of interest in civil matters; dates of birth immediately come to
>> mind.
> I agree.
>
>> So when Brooks Harris presents his API to his stakeholders, I think a
>> more thorough explanation of why date-time expressions before 1972
>> will be "
>> considered either inaccurate or invalid" will be needed.
>
> It is typically warned that date and time before 1972 cannot be
> accurately represented with NTP or POSIX, for examples. These
> timescale's origins precede 1972-01-01T00:00:00Z (UTC) =
> 1972-01-01T00:00:10 (TAI) and seek to represent date-time counting
> *forward*. They give no consideration to date-time accuracy before
> 1972, but operate on proleptic scales convenient for computation.
> This is generally true with widely available timekeeping services on
> OSs, systems, languages, and many typical applications because so
> many of them implement mechanisms based on the heritage of the POSIX
> timekeeping mechanisms, complete with its flaws with respect to
> representing UTC and Leap Seconds.
>
> In the discussions I've been involved with many people argued
> strenuously "we don't care about the past, only accurate date-time
> going forward!". The reason I'm choosing to ignore the subject of
> accurate date-times before 1972 is not that its not important, but
> probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
> - its just too expansive a topic to tackle in some commonly accepted
> way. For date-time before 1972 you've got to switch to some other
> timescale depending on the purpose at hand.
I figured it out the difference between GMD and UTC for POSIX. There
was an 81 microsecond error, At the time, most UNIX boxes kept time to
the nearest second, synchronized to a hairy wrist. There were advanced
systems that could do milliseconds, and in the 1980s a few that had
microsecond resolution, but we chained them to GPS via NTP, so the
error was multiple milliseconds, depending on everything.
Joe Gwinn
From brooks at edlmax.com Sun Mar 8 11:41:04 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 11:41:04 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <20150307200111.GA24366@ucolick.org>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
Message-ID: <54FC6D90.1070506@edlmax.com>
Hi Steve,
On 2015-03-07 03:01 PM, Steve Allen wrote:
> On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ:
>> It is typically warned that date and time before 1972 cannot be
>> accurately represented with NTP or POSIX, for examples.
> I would say that for PTP
> * all seconds are always SI seconds
> * seconds after 1972-01-01 correspond to (TAI - 10)
> * seconds before 1972-01-01 do not align with civil time
> * in particular, 1970-01-01 in PTP does not correspond to
> any event in any time scale which was then in use,
> but that does not matter
> For PTP it is the uniformity going forward that is the goal.
Keep in mind PTP is for ".. Networked Measurement and Control Systems",
so its first objective is for things like process control, hence its
primary timescale is "TAI-like". Civil time, or UTC, is a secondary
concideration, but it has mechanisms to communicate UTC
(currentUtcOffset, leap59, leap61). It does not specify the UTC rules by
which these are set, relying on the UTC background specifications for that.
leap59 and leap61 are Leap Second announce signals, set 12 hours prior
to the insert. There has been discussion about when the official
announcements and expiration should be announced. ITU Rec 460 says
"...at least eight weeks in advance". PTP can't do that, a point to keep
in mind.
> I would say that the intent NTP and POSIX is to correspond to civil
> time in contemporary use. Therefore, for dates before 1972-01-01
> NTP and POSIX are counting seconds of UT.
First let me compliment you on all your excellent work and research at
http://www.ucolick.org/~sla/leapsecs/. This is an invaluable resource
and I have learned much from it. Thank you.
This paragraph in your email had me scratching my head a little. So,
first, off to your time pages to learn more carefully about UT. I think
I see what you mean generally.
My view is the NTP and POSIX are abstract timescales constructed for
convenient "civil" timekeeping calculation, albeit with their Leap
Second flaws. I think I would suggest your statement would be better as
" .. for dates before 1972-01-01 NTP and POSIX are counting seconds on a
proleptic scale that extrapolates the SI Second prior to 1972-01-01.".
This seems clear epecially in NTP, where RFC 5905 states "It should be
noted that strictly speaking, UTC did not exist prior to 1 January 1972,
but it is convenient to assume it has existed for all eternity, even if
all knowledge of historic leap seconds has been lost."
It seems to me NTP and POSIX as well as other timescales concerned with
"civil time", are essentially disconnected from "reality", expressing
"idealized" measurement scales. UTC is an idealized scale expressing an
approximation of reality derived from UT1, and UT1 will probably always
undergo some refinement and the sciences advance. I think none of the
"civil" timescales are counting in UT - they are measured in SI Seconds,
even when prolpetic to 1972.
Am I missing something here?
>
> For dates after 1972-01-01 I would say that NTP and POSIX are both
> confused
You bet
> about whether they are counting SI seconds or UT days.
Can you be more specific about what you mean by this? I think I
understand your general meaning, that the "confusion", or the mis-match
between the NTP and POSIX and UTC, lies with their methods of accounting
for LOD. By "UT days" do you mean "86400 seconds per day"?
> Therein, of course, lies the basis of this LEAPSECS list.
Sure. Well, at least, therein lies *one reason* for this LEAPSECS list. :-)
>
> I see it as inevitable that the confusion must end, therefore NTP and
> POSIX will eventually be unambiguous that they are counting SI
> seconds. That means that, eventually, any general purpose time scale
> intended to correspond to civil time will be a piecewise continuous
> time scale. Such general purpose time scales will have a date at
> which they switch from counting UT days to counting SI seconds.
>
> Deciding on that date, and how it will be implemented and understood,
> is what we hope the ITU-R will accomplish at WRC-15.
Can you elaborate on this point as you've stated it? What exactly do you
mean "switch from counting UT days to counting SI seconds"? This doesn't
sound quite like what I understand the question(s) at WRC-15 to be.
>
>> For date-time before 1972 you've got to switch to some
>> other timescale depending on the purpose at hand.
> Exactly so. Before 1972 civil time was not SI seconds.
I understand the proper SI second sprung into existence as of 1972. But
it seems to me civil time as kept by NTP and POSIX before 1972 is
measured in proleptically exrapolated SI seconds. Of course this scale
does not correspond with "actual" historical date and time or UT1. What
am I missing?
Thanks,
-Brooks
>
> --
> Steve Allen WGS-84 (GPS)
> UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
> 1156 High Street Voice: +1 831 459 3046 Lng -122.06015
> Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From brooks at edlmax.com Sun Mar 8 12:24:42 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 12:24:42 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <20150307185040843495.de5a6666@comcast.net>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307185040843495.de5a6666@comcast.net>
Message-ID: <54FC77CA.8000205@edlmax.com>
On 2015-03-07 06:50 PM, Joseph Gwinn wrote:
> On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
>> In the discussions I've been involved with many people argued
>> strenuously "we don't care about the past, only accurate date-time
>> going forward!". The reason I'm choosing to ignore the subject of
>> accurate date-times before 1972 is not that its not important, but
>> probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
>> - its just too expansive a topic to tackle in some commonly accepted
>> way. For date-time before 1972 you've got to switch to some other
>> timescale depending on the purpose at hand.
> I figured it out the difference between GMD and UTC for POSIX. There
> was an 81 microsecond error, At the time, most UNIX boxes kept time to
> the nearest second, synchronized to a hairy wrist. There were advanced
> systems that could do milliseconds, and in the 1980s a few that had
> microsecond resolution, but we chained them to GPS via NTP, so the
> error was multiple milliseconds, depending on everything.
Hi Joe,
I see the difficulties with UTC implementations and the questions at
ITU-R stemming from the historical and legacy misalignment of the
timekeeping mechanisms of the c language and POSIX and the UTC
specifications. Perhaps that's obvious. I'm not criticizing anybody
anywhere for this, its just the way its come about.
I think the only way the industry can eventually converge on reliable
"civil time" representation is to refine the underlying time mechanisms
in POSIX in some manner that allows a migration to a more comprehensive
UTC implementation. I think if a new new POSIX time specification were
to take shape it would add an option to the the conversation at ITU-R -
instead of simply "to kill Leap Seconds or not" they'd also have "a
viable migration path to comprehensive UTC timekeeping implementation"
to consider.
We understand the folks at POSIX have grappled with this topic in the
past and run into all sorts of difficulty. Given the current state of
affairs, do you think there's any way IEEE and POSIX could reengage this
topic?
-Brooks
>
> Joe Gwinn
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From zefram at fysh.org Sun Mar 8 12:45:00 2015
From: zefram at fysh.org (Zefram)
Date: Sun, 8 Mar 2015 16:45:00 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54F9FA4C.7060805@edlmax.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
Message-ID: <20150308164500.GA14280@fysh.org>
Brooks Harris wrote:
>that allows the epochs to slip with each Leap Second in the manner
>NTP and POSIX do, which is, as you call it, "scalar".
I think you understand by the word "scalar" something very different from
what I mean. By "scalar value" I mean a value consisting of a single
number, such as a Unix time_t value or an NTP time value. Non-scalar time
values include anything that separates date from time-of-day.
> whereas with the NTP and POSIX implementations of "UTC-like"
>timescales, the epochs *slip*, essentially creating a new timescale
>with a different epoch
This is a legitimate view of the NTP and POSIX systems, which has a
certain amount of theoretical value.
>On 2015-03-05 01:29 PM, Zefram wrote:
>>Brooks Harris wrote:
>>No, there is no contradiction there. The table makes no claim about
>>the correspondence between TAI and UTC at any particular point in time.
>It does if your objective is to link PTP time to the fixed epoch of
No, your objective doesn't fundamentally change what the table says.
>> The currentUtcOffset (meaning (TAI-UTC)/s)
>>is not defined for all points in time, and during the rubber-seconds
>>era of UTC it takes on non-integral values.
>
>Not in a practical timescale implementation.
If your concept of a "practical timescale implementation" excludes
rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your
"practical timescale implementation". That still doesn't change what
happens when one *does* consider rubber-seconds UTC. You wishing that
it didn't exist doesn't make it go away.
>In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>= 10s.
Where do you get this idea from? You've cited no source for it.
You appear to have plucked it from thin air.
> Official TAI exists
>from the origin of 1958-01-01T00:00:00 (TAI).
That's a misunderstanding of the nature of the TAI `epoch'. It is
not the case that TAI existed from the epoch onwards and did not exist
before. TAI has existed to varying degrees from mid-1955 onwards, and
historically nothing special happened to it on 1958-01-01. That date
only became special in retrospect, in late 1958. That's when the time
scale was established in a form that we'd recognise (though not with its
present name), counting units of atomic seconds and labelling them by MJD
and equivalents. The specialness of 1958-01-01 is merely that those MJD
labels were aligned such that TAI coincided with UT2(USNO) on that date.
TAI timestamps in early 1958 are necessarily retrospective (more so
than TAI timestamps from 1959 onwards are), and such retrospective TAI
timestamps can be applied all the way back to the start of continuous
atomic clock operations in 1955.
Are you just making an arbitrary decision that TAI from 1958 onwards is
"official" (even where retrospective) and that TAI prior to 1958 is "not
official" (even where well defined)? If you are choosing an arbitrary
cutoff for the purposes of your project, you should be explicit about
that scope and about its arbitrariness.
> Thats where you need
>a timescale that is an integral second measure proleptic to
>1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain.
>With that, the PTP epoch is 1970-01-01T00:00:00 (TAI) =
>1969-12-31T23:59:50Z (UTC).
In addition to the very dubious nature of the "need" for a specific
proleptic extension of integral-seconds UTC, you here make the jump from
*a* proleptic integral UTC to *the* time scale you are constructing.
There are many possible proleptic extensions of integral-seconds UTC,
and you have consistently failed to explain why one must specifically
use the one that has no pre-1972 leap events.
>By the way, I think its unfortunate they didn't specify the epoch as
>"1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would
>coincide exactly with POSIX "the Epoch".
It would coincide exactly only in the context of your fictitious
leap-seconds-but-no-actual-leaps pre-1972 UTC. Given the fundamental
differences between PTP and POSIX time values, having the epochs coincide
to any appreciable degree invites confusion. Having them as close as
they are (about 8 s using real UTC, 10 s using your fictitious UTC)
is bad enough; getting them as close as 2 s (and especially the exact
coincidence with your fictitious UTC) would be asking for trouble.
>I think you mean if you are attempting to map into the "rubber-band
>era" you could interpret the currentUtcOffset value to be
>non-integral, but that's not explicit in the table.
Indeed, that's not explicit. It's implied by the basic definition of
currentUtcOffset (as the difference between TAI and UTC) combined with
the fundamental behaviour of rubber-seconds UTC.
> In fact I see
>currentUtcOffset as being defined as integral seconds.
The protocol field is defined to only accommodate integral values,
but annex B clearly looks at the theory beyond the scope of the actual
protocol. The integral nature of the field means that it's impossible
to handle rubber-seconds UTC by running PTP. This will not be a problem
until a copy of IEEE 1588 falls through a wormhole into the 1960s.
>"NTP Seconds = PTP Seconds + 2 208 988 800 - currentUtcOffset"
>describes the absolute seconds offset from the NTP prime epoch era 0
>to the PTP Epoch.
The phrases "NTP Seconds" and "PTP Seconds" clearly refer to the scalar
values used in those protocols. The table is directly describing a
relationship between those scalar values, and does not mention epochs
at all.
> If your implementation is to keep those reference
>points fixed, that tells you the constant offset.
If the epochs were both well defined, in such a way that each could be
meaningfully represented on the other protocol's time scale, then the
relationship between the scalar values would be sufficient to perform
this conversion and potentially determine a time offset between the
epochs. But the NTP epoch is not so well defined. The NTP epoch is
not a specific point in time, and so cannot be converted into the PTP
time scale. It couldn't be so converted even if the PTP time scale
extended back to 1900, which it doesn't.
>I have constructed an implementation of an experimental reference
>timescale with fixed epoch offsets starting at 1900-01-01T00:00:00Z
>(UTC) = 1900-01-01T00:00:10 (TAI).
Once again, you should not use the labels "TAI" and "UTC" for such
timestamps. Where you have invented time scales, use distinctive labels
for them. Don't claim that they're the actual TAI and UTC.
-zefram
From zefram at fysh.org Sun Mar 8 13:09:59 2015
From: zefram at fysh.org (Zefram)
Date: Sun, 8 Mar 2015 17:09:59 +0000
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FC6D90.1070506@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com>
Message-ID: <20150308170959.GB14280@fysh.org>
Brooks Harris wrote:
>It seems to me NTP and POSIX as well as other timescales concerned
>with "civil time", are essentially disconnected from "reality",
>expressing "idealized" measurement scales.
That's very much what they're not. TT is idealised, and TAI less so.
> I
>think none of the "civil" timescales are counting in UT - they are
>measured in SI Seconds, even when prolpetic to 1972.
NTP doesn't deal with pre-1972 time at all. (No, the nominal epoch
doesn't count.)
POSIX time_t notionally can represent pre-1972 times, but in practice no
Unix system of that era was synchronised to UTC. Any use of time_t for
precise pre-1972 time is heavily retrospective, and the interpretation
is more governed by the application than by the POSIX standard. Wild
pre-1972 Unix time_t values heavily predate the POSIX standard, and their
interpretation has little to do with UTC. They are understood to be vague
UT with usually very poor synchronisation (via the operator's wristwatch).
Actual civil time, as used in the real world, was rarely precise pre-1972,
certainly not much to do with SI seconds. Historically civil time has,
over the long term and with large short-term excursions, been synchronised
to the solar day, so effectively to UT.
>I understand the proper SI second sprung into existence as of 1972.
You understand incorrectly. As with the existence of TAI (which I
discussed in my previous message), the development of the SI second
happened in stages. We can start in 1948, with the definition of
Ephemeris Time, which is the first time we got a definition for the
second that was not derived from the solar day. The ephemeris second is
instead defined in terms of the Earth's orbit around the Sun. ET was
adopted by the IAU in 1952. In 1958 the caesium second was defined,
the definition being chosen to match the value of the ephemeris second.
SI was established in 1960, and at that time adopted the ephemeris second
as the SI second. In 1967 SI was revised to adopt the caesium second
as the SI second, and in 1997 the definition was refined to account for
blackbody radiation.
So the value of the SI second was established in 1948; the present
definition originates in 1958 but its full present form only goes back to
1997; SI (and so the concept of "SI second") originated in 1960; and the
SI second acquired its present basic definition in 1967. Any of these
dates could be taken as the inception of the SI second, but the only one
that could really be described as the SI second "springing into existence"
is the establishment of SI in 1960. Nothing relevant happened in 1972.
-zefram
From joegwinn at comcast.net Sun Mar 8 13:34:47 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Sun, 8 Mar 2015 13:34:47 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <20150308170959.GB14280@fysh.org>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <20150308170959.GB14280@fysh.org>
Message-ID: <20150308133447031017.0d4680fa@comcast.net>
On Sun, 8 Mar 2015 17:09:59 +0000, Zefram wrote:
> Brooks Harris wrote:
>> It seems to me NTP and POSIX as well as other timescales concerned
>> with "civil time", are essentially disconnected from "reality",
>> expressing "idealized" measurement scales.
>
> That's very much what they're not. TT is idealised, and TAI less so.
>
>> I
>> think none of the "civil" timescales are counting in UT - they are
>> measured in SI Seconds, even when prolpetic to 1972.
>
> NTP doesn't deal with pre-1972 time at all. (No, the nominal epoch
> doesn't count.)
>
> POSIX time_t notionally can represent pre-1972 times, but in practice no
> Unix system of that era was synchronised to UTC. Any use of time_t for
> precise pre-1972 time is heavily retrospective, and the interpretation
> is more governed by the application than by the POSIX standard. Wild
> pre-1972 Unix time_t values heavily predate the POSIX standard, and their
> interpretation has little to do with UTC. They are understood to be vague
> UT with usually very poor synchronisation (via the operator's wristwatch).
The actual timescale in POSIX is a found to Seconds Since the Epoch,
and fractions thereof. Negative values are not currently defined.
Joe Gwinn
From joegwinn at comcast.net Sun Mar 8 13:46:31 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Sun, 8 Mar 2015 13:46:31 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FC77CA.8000205@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307185040843495.de5a6666@comcast.net>
<54FC77CA.8000205@edlmax.com>
Message-ID: <20150308134631690955.35263f27@comcast.net>
On Sun, 08 Mar 2015 12:24:42 -0400, Brooks Harris wrote:
>
> On 2015-03-07 06:50 PM, Joseph Gwinn wrote:
>> On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
>>> In the discussions I've been involved with many people argued
>>> strenuously "we don't care about the past, only accurate date-time
>>> going forward!". The reason I'm choosing to ignore the subject of
>>> accurate date-times before 1972 is not that its not important, but
>>> probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
>>> - its just too expansive a topic to tackle in some commonly accepted
>>> way. For date-time before 1972 you've got to switch to some other
>>> timescale depending on the purpose at hand.
>> I figured it out the difference between GMD and UTC for POSIX. There
>> was an 81 microsecond error, At the time, most UNIX boxes kept time to
>> the nearest second, synchronized to a hairy wrist. There were advanced
>> systems that could do milliseconds, and in the 1980s a few that had
>> microsecond resolution, but we chained them to GPS via NTP, so the
>> error was multiple milliseconds, depending on everything.
> Hi Joe,
>
> I see the difficulties with UTC implementations and the questions at
> ITU-R stemming from the historical and legacy misalignment of the
> timekeeping mechanisms of the c language and POSIX and the UTC
> specifications. Perhaps that's obvious. I'm not criticizing anybody
> anywhere for this, its just the way its come about.
>
> I think the only way the industry can eventually converge on reliable
> "civil time" representation is to refine the underlying time
> mechanisms in POSIX in some manner that allows a migration to a more
> comprehensive UTC implementation. I think if a new new POSIX time
> specification were to take shape it would add an option to the the
> conversation at ITU-R - instead of simply "to kill Leap Seconds or
> not" they'd also have "a viable migration path to comprehensive UTC
> timekeeping implementation" to consider.
>
> We understand the folks at POSIX have grappled with this topic in the
> past and run into all sorts of difficulty. Given the current state of
> affairs, do you think there's any way IEEE and POSIX could reengage
> this topic?
The biggest problem was that the time folk couldn't stop arguing, and
come to a solution that met all of POSIX's technical requirements. Nor
should the arguments be held in the POSIX committee, most of which were
totally unable to follow the arguments. The committee finally threw
the time folk out into the snow and settled for minimal changes. I did
get the statement that each day has exactly 86,400 seconds written into
the standard, and that although it resembled UTC is was not in fact
UTC, to cut off the common misinterpretation that POSIX time was UTC.
I published the email threads some time ago. Anyway, if the time folk
could come to agreement and present one proposal, there is a chance.
Also listed in the email threads were the requirements, and one of the
requirements is that POSIX time had to work in a reasonable way even in
totally isolated systems, which have no way to know about leap seconds.
Joe Gwinn
From brooks at edlmax.com Sun Mar 8 14:58:46 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 14:58:46 -0400
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150308164500.GA14280@fysh.org>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
<20150308164500.GA14280@fysh.org>
Message-ID: <54FC9BE6.9080301@edlmax.com>
On 2015-03-08 12:45 PM, Zefram wrote:
> Brooks Harris wrote:
>> that allows the epochs to slip with each Leap Second in the manner
>> NTP and POSIX do, which is, as you call it, "scalar".
> I think you understand by the word "scalar" something very different from
> what I mean. By "scalar value" I mean a value consisting of a single
> number, such as a Unix time_t value or an NTP time value. Non-scalar time
> values include anything that separates date from time-of-day.
OK, yes, we're thinking of it differently, I guess, or at least I may
have misrepreented your meaning in my pose. But as you explain it here
thats what I'm thinking too. Any given value of time_t or an NTP time
value has "lost all knowledge of Leap Seconds" and so has slipped its
epoch with each Leap Second, in effect creating multiple timescales.
I must admit I didn't understand the significance of this subtly for a
while -
David Wells writes:
The NTP Timescale and Leap Seconds
http://www.eecis.udel.edu/~mills/leap.html
3. How NTP and POSIX Reckon with Leap Seconds
"... the conversion is in effect reset to UTC as each broadcast timecode
is received. Thus, when a leap second is inserted in UTC and
subsequently in NTP or POSIX, knowledge of all previous leap seconds is
lost."
"Another way to describe this is to say there are as many NTP or POSIX
timescales as historic leap seconds. In effect, a new timescale is
reestablished after each new leap second. Thus, all previous leap
seconds, not to mention the apparent origin of the timescale itself,
lurch backward one second as each new timescale is established. ..."
I'd read that many times before it sunk in. Oh! The epochs are actually
shifting! And so there are multiple timescales! Wow! Now I get it!
This is what I understood your use of "scalar" to be referring to.
>
>> whereas with the NTP and POSIX implementations of "UTC-like"
>> timescales, the epochs *slip*, essentially creating a new timescale
>> with a different epoch
> This is a legitimate view of the NTP and POSIX systems, which has a
> certain amount of theoretical value.
I agree, "a certain amount of theoretical value", and, indeed, a fairly
large amount of practical timekeeping capability. If implemented
correctly, NTP and POSIX accurately represent date and time-of-day
*except* on the Leap Seconds themselves. But, of course time_t's epoch
is slipping about with respect to post 1972 UTC.
>
>> On 2015-03-05 01:29 PM, Zefram wrote:
>>> Brooks Harris wrote:
>>> No, there is no contradiction there. The table makes no claim about
>>> the correspondence between TAI and UTC at any particular point in time.
>> It does if your objective is to link PTP time to the fixed epoch of
> No, your objective doesn't fundamentally change what the table says.
I didn't say it changed the table in some way. I said I'm using those
values to calculate the offset between NTP prime epoch of era 0 and 1972
UTC. I'm then using that as a *fixed* epoch of my timescale.
>
>>> The currentUtcOffset (meaning (TAI-UTC)/s)
>>> is not defined for all points in time, and during the rubber-seconds
>>> era of UTC it takes on non-integral values.
>> Not in a practical timescale implementation.
> If your concept of a "practical timescale implementation" excludes
> rubber-seconds UTC, then sure, rubber-seconds UTC doesn't arise in your
> "practical timescale implementation".
Right. Same as NTP and POSIX - they don't represent accurate date-time
before 1972.
> That still doesn't change what
> happens when one *does* consider rubber-seconds UTC.
Yes, you need to switch to an alternate timescale. There *is* an implied
timescale with non-integral measures from 1961 to 1972 that doesn't have
a name. That's what you need in that period if that's your purpose. In
*my* timescale, and NTP and POSIX, this period lies in the "inaccurate
proleptic integral seconds period before 1972".
> You wishing that
> it didn't exist doesn't make it go away.
I didn't make it go away. I ignore it for purposes of timekeeping after
1972, replacing it with a "proleptic extrapolation of seconds prior to
1972 for convenience of calculation" the same way NTP and POSIX do.
time_t doesn't know anything about the rubber-band era in lies within.
>
>> In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>> = 10s.
> Where do you get this idea from? You've cited no source for it.
> You appear to have plucked it from thin air.
No, not from thin air, its very clear -
IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
timePropertiesDS.currentUtcOffset = TAI ? UTC."... "NOTE?As of 0 hours 1
January 2006 UTC, UTC was behind TAI by 33 seconds."
>
>> Official TAI exists
> >from the origin of 1958-01-01T00:00:00 (TAI).
>
> That's a misunderstanding of the nature of the TAI `epoch'.
Not a misunderstanding, I don't think. A "recasting" of its use, perhaps.
> It is
> not the case that TAI existed from the epoch onwards and did not exist
> before. TAI has existed to varying degrees from mid-1955 onwards, and
> historically nothing special happened to it on 1958-01-01. That date
> only became special in retrospect, in late 1958. That's when the time
> scale was established in a form that we'd recognise (though not with its
> present name), counting units of atomic seconds and labelling them by MJD
> and equivalents. The specialness of 1958-01-01 is merely that those MJD
> labels were aligned such that TAI coincided with UT2(USNO) on that date.
> TAI timestamps in early 1958 are necessarily retrospective (more so
> than TAI timestamps from 1959 onwards are), and such retrospective TAI
> timestamps can be applied all the way back to the start of continuous
> atomic clock operations in 1955.
Right. But like the "rubber-band era" they are beside the point of
timekeeping after 1972, and you could construct a scale for that period
for that purpose.
>
> Are you just making an arbitrary decision that TAI from 1958 onwards is
> "official" (even where retrospective) and that TAI prior to 1958 is "not
> official" (even where well defined)?
The only time point I consider "uncontroversially official" is
1972-01-01T00:00:00Z (UTC) = 1972-01-01 00:00:10 (TAI). The NTP spec is
quite explicit in RFC 5905, Figure 4: Interesting Historic NTP Dates.
The POSIX "the Epoch" spec is *intentionally* vague. PTP's epoch,
1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate proleptic
TAI seconds prior to 1972-01-01 00:00:10 (TAI). As commonly used, most
modern systems operate at integral seconds, and most seem to align to
NTP's figure Figure 4: Interesting Historic NTP Dates.
> If you are choosing an arbitrary
> cutoff for the purposes of your project, you should be explicit about
> that scope and about its arbitrariness.
Yes. Its objective is accurate UTC after 1972-01-01 00:00:10 (TAI) =
1972-01-01T00:00:00Z (UTC) while accommodating the commonly used primary
proleptic epochs of several important timekeeping systems, NTP, PTP, and
POSIX.
>
>> Thats where you need
>> a timescale that is an integral second measure proleptic to
>> 1972-01-01T00:00:00Z (UTC), the timescale I keep trying to explain.
>> With that, the PTP epoch is 1970-01-01T00:00:00 (TAI) =
>> 1969-12-31T23:59:50Z (UTC).
> In addition to the very dubious nature of the "need" for a specific
> proleptic extension of integral-seconds UTC, you here make the jump from
> *a* proleptic integral UTC to *the* time scale you are constructing.
> There are many possible proleptic extensions of integral-seconds UTC,
> and you have consistently failed to explain why one must specifically
> use the one that has no pre-1972 leap events.
It hinges of NTP's specification, including NTP's figure Figure 4:
Interesting Historic NTP Dates.
The NTP "prime epoch of era 0" *includes* the initial ten-second TAI-UTC
offset imposed at 1972. There is a 10 second offset from the NTP prime
epoch until the first actual Leap Second on 1972-06-30T23:59:60 ->
1972-07-01T00:00:00.
(By the way, there is no generally accepted term for this initial
ten-second TAI-UTC offset I'm aware of. They are often lumped in as
"Leap Seconds", but that's not quite right.)
RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.
| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch to
1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
definition) so the seconds offset to the NTP prime epoch includes this,
that is, the initial TAI-UTC 10s is in effect at the beginning of the
NTP timescale.
>
>> By the way, I think its unfortunate they didn't specify the epoch as
>> "1970-01-01T00:00:10 (TAI)" (note the 10s) because then it would
>> coincide exactly with POSIX "the Epoch".
> It would coincide exactly only in the context of your fictitious
> leap-seconds-but-no-actual-leaps pre-1972 UTC. Given the fundamental
> differences between PTP and POSIX time values, having the epochs coincide
> to any appreciable degree invites confusion. Having them as close as
> they are (about 8 s using real UTC, 10 s using your fictitious UTC)
> is bad enough; getting them as close as 2 s (and especially the exact
> coincidence with your fictitious UTC) would be asking for trouble.
Ah, no. The PTP timekeeping community wisely ignores all the
shenanigan's about "the rubber-band era" explained in the PTP spec
because its too complex and not required for UTC after 1972.
>
>> I think you mean if you are attempting to map into the "rubber-band
>> era" you could interpret the currentUtcOffset value to be
>> non-integral, but that's not explicit in the table.
> Indeed, that's not explicit. It's implied by the basic definition of
> currentUtcOffset (as the difference between TAI and UTC) combined with
> the fundamental behaviour of rubber-seconds UTC.
>
>> In fact I see
>> currentUtcOffset as being defined as integral seconds.
> The protocol field is defined to only accommodate integral values,
> but annex B clearly looks at the theory beyond the scope of the actual
> protocol. The integral nature of the field means that it's impossible
> to handle rubber-seconds UTC by running PTP.
Exactly. So, who cares? And why all the fuss about it? OK, maybe, maybe,
the "theory" as explained in it is correct (I don't think so, but..) but
it just doesn't matter.
> This will not be a problem
> until a copy of IEEE 1588 falls through a wormhole into the 1960s.
Yes, so, why are we going on about it? If you need to account for the
"rubber-band era" or any other date-time before 1972 you've got to
switch to some other timescale for the purpose.
>
>> "NTP Seconds = PTP Seconds + 2 208 988 800 - currentUtcOffset"
>> describes the absolute seconds offset from the NTP prime epoch era 0
>> to the PTP Epoch.
> The phrases "NTP Seconds" and "PTP Seconds" clearly refer to the scalar
> values used in those protocols. The table is directly describing a
> relationship between those scalar values, and does not mention epochs
> at all.
True. But they define the relation between epochs if you interpret them
that way, which is what I'm doing to place each epoch at a fixed offset
proleptic to 1972.
>
>> If your implementation is to keep those reference
>> points fixed, that tells you the constant offset.
> If the epochs were both well defined, in such a way that each could be
> meaningfully represented on the other protocol's time scale, then the
> relationship between the scalar values would be sufficient to perform
> this conversion and potentially determine a time offset between the
> epochs.
Right.
> But the NTP epoch is not so well defined. The NTP epoch is
> not a specific point in time,
Sure it is. The *the prime epoch, or base date of era 0, is 0 h 1
January 1900 UTC" and is 2272060800 seconds before the "First day UTC".
> and so cannot be converted into the PTP
> time scale. It couldn't be so converted even if the PTP time scale
> extended back to 1900, which it doesn't.
Sure you can *if* you extrapolate propleptic TAI back to 1900 (or
conceptually, to the indefinite past).
>
>> I have constructed an implementation of an experimental reference
>> timescale with fixed epoch offsets starting at 1900-01-01T00:00:00Z
>> (UTC) = 1900-01-01T00:00:10 (TAI).
> Once again, you should not use the labels "TAI" and "UTC" for such
> timestamps. Where you have invented time scales, use distinctive labels
> for them. Don't claim that they're the actual TAI and UTC.
I agree, its a bit careless, but I need a name for them you or somebody
might accept. I'm still cogitating on that.
-Brooks
>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From brooks at edlmax.com Sun Mar 8 15:40:25 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 15:40:25 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <20150308170959.GB14280@fysh.org>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <20150308170959.GB14280@fysh.org>
Message-ID: <54FCA5A9.2050504@edlmax.com>
On 2015-03-08 01:09 PM, Zefram wrote:
> Brooks Harris wrote:
>> It seems to me NTP and POSIX as well as other timescales concerned
>> with "civil time", are essentially disconnected from "reality",
>> expressing "idealized" measurement scales.
> That's very much what they're not. TT is idealised, and TAI less so.
I meant "idealized" in the sense of convenient counting methods. They
are not accurate in any respect before 1972. If it were up to me I'd
just abolish legacy timescales and force everybody to use UTC. That's
not gonna happen, we obviously must accommodate existing systems.
>
>> I
>> think none of the "civil" timescales are counting in UT - they are
>> measured in SI Seconds, even when prolpetic to 1972.
> NTP doesn't deal with pre-1972 time at all. (No, the nominal epoch
> doesn't count.)
Right. You can, if you like, generate a date and time from a given
seconds offset from NTPs' prime epoch era 0. Its inaccuracy with respect
to some other pre-1972 timescale you wanted to compare it to could be
calculated. That might be useful for some purpose, but its not the
objective.
>
> POSIX time_t notionally can represent pre-1972 times, but in practice no
> Unix system of that era was synchronised to UTC.
We're not caring about what systems did then. We're caring about what
they do now and in the future.
> Any use of time_t for
> precise pre-1972 time is heavily retrospective, and the interpretation
> is more governed by the application than by the POSIX standard.
Exactly.
> Wild
> pre-1972 Unix time_t values heavily predate the POSIX standard, and their
> interpretation has little to do with UTC. They are understood to be vague
> UT with usually very poor synchronisation (via the operator's wristwatch).
Right. So what?
>
> Actual civil time, as used in the real world, was rarely precise pre-1972,
> certainly not much to do with SI seconds. Historically civil time has,
> over the long term and with large short-term excursions, been synchronised
> to the solar day, so effectively to UT.
And that's what we'd hope to make more clear, explicit, and reliable in
the future. The past is past. What can we do now?
>
>> I understand the proper SI second sprung into existence as of 1972.
> You understand incorrectly. As with the existence of TAI (which I
> discussed in my previous message), the development of the SI second
> happened in stages. We can start in 1948, with the definition of
> Ephemeris Time, which is the first time we got a definition for the
> second that was not derived from the solar day. The ephemeris second is
> instead defined in terms of the Earth's orbit around the Sun. ET was
> adopted by the IAU in 1952. In 1958 the caesium second was defined,
> the definition being chosen to match the value of the ephemeris second.
> SI was established in 1960, and at that time adopted the ephemeris second
> as the SI second. In 1967 SI was revised to adopt the caesium second
> as the SI second, and in 1997 the definition was refined to account for
> blackbody radiation.
Yes yes I know.
>
> So the value of the SI second was established in 1948; the present
> definition originates in 1958 but its full present form only goes back to
> 1997; SI (and so the concept of "SI second") originated in 1960; and the
> SI second acquired its present basic definition in 1967. Any of these
> dates could be taken as the inception of the SI second, but the only one
> that could really be described as the SI second "springing into existence"
> is the establishment of SI in 1960. Nothing relevant happened in 1972.
Yes, I know. What happened in 1972 was the magic moment when TAI - 10s =
UTC. All the complex, if interesting, history of the development of TAI
and UTC is over the damn. Discussion of it is all down in the weeds
until it becomes mostly locked-in in 1972.
I was responding to Steve's "UT" discussion and his comment "Before 1972
civil time was not SI seconds".
-Brooks
>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From zefram at fysh.org Sun Mar 8 15:43:33 2015
From: zefram at fysh.org (Zefram)
Date: Sun, 8 Mar 2015 19:43:33 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54FC9BE6.9080301@edlmax.com>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net>
<54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
<20150308164500.GA14280@fysh.org> <54FC9BE6.9080301@edlmax.com>
Message-ID: <20150308194333.GZ8710@fysh.org>
Brooks Harris wrote:
>On 2015-03-08 12:45 PM, Zefram wrote:
>>Brooks Harris wrote:
>>>In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>>>= 10s.
>>Where do you get this idea from? You've cited no source for it.
>>You appear to have plucked it from thin air.
>
>No, not from thin air, its very clear -
>
>IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
>timePropertiesDS.currentUtcOffset = TAI - UTC."... "NOTE-As of 0
>hours 1 January 2006 UTC, UTC was behind TAI by 33 seconds."
That clause does not specify a currentUtcOffset value for 1969-12-31.
It gives a general definition, augmented with information that implies a
currentUtcOffset value for 2006-01-01 (of 33 s). I'm really not seeing
how you get from that to a value of 10 s for 1969-12-31. Taking UTC to
include the rubber seconds era gives a varying non-integral value near 8 s
for 1969-12-31. Alternatively, your view that the pre-1972 history isn't
`really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.
If you're trying to use this statement as justification for your time
scale, then this is circular reasoning; you're begging the question.
>Right. But like the "rubber-band era" they are beside the point of
>timekeeping after 1972,
They would be beside the point if you hadn't raised the issue yourself.
You're expending a lot of effort on pre-1972 times that are all irrelevant
for this purpose. The actual time of the NTP epoch is beside the point.
> PTP's
>epoch, 1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate
>proleptic TAI seconds prior to 1972-01-01 00:00:10 (TAI).
1972 is another date that doesn't mark the beginning of TAI. The name
"TAI" arose in 1971, but the BIH had actually been operating the service
in a pretty modern form for years. TAI times in 1970 are not proleptic.
>RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.
>
>| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
>| 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
>
>Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch
>to 1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
>remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
>definition) so the seconds offset to the NTP prime epoch includes
>this, that is, the initial TAI-UTC 10s is in effect at the beginning
>of the NTP timescale.
You have misinterpreted that table. The heading of the column you're
referring to is "NTP Timestamp". There's no claim there that the
2272060800 is an actual number of seconds between two events. Rather,
2272060800 is the NTP scalar value describing 1972-01-01 00:00:00 UTC.
As you have repeatedly pointed out, NTP doesn't count leap seconds.
The difference between two NTP timestamps does not reflect the number
of leap seconds that occurred in that interval. The 2272060800 value
implies nothing at all about leap seconds between 1900 and 1972.
Also note the next entry in the table:
| 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th |
| | | | | Century |
This 3155587200 value is *also* an exact multiple of 86400. If it were
to be interpreted as a pure count of seconds, it would imply that there
were a total of zero leap seconds between 1900-01-01 and 1999-12-31, and
similarly a total of zero leap seconds between 1972-01-01 and 1999-12-31.
That would contradict the uncontroversial post-1972 leap second schedule.
>>But the NTP epoch is not so well defined. The NTP epoch is
>>not a specific point in time,
>Sure it is. The *the prime epoch, or base date of era 0, is 0 h 1
>January 1900 UTC"
1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
extend back that far. The NTP epoch is, in that respect, fictitious.
> and is 2272060800 seconds before the "First day
>UTC".
And that's your misunderstanding of the NTP table again.
-zefram
From imp at bsdimp.com Sun Mar 8 16:57:14 2015
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 8 Mar 2015 14:57:14 -0600
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <20150307185040843495.de5a6666@comcast.net>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307185040843495.de5a6666@comcast.net>
Message-ID: <04764C33-0331-49A5-B93E-630BA7E65694@bsdimp.com>
> On Mar 7, 2015, at 4:50 PM, Joseph Gwinn wrote:
>
> On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
>> Hi Gerard,
>>
>> On 2015-03-07 12:04 PM, G Ashton wrote:
>>>
>>> Brooks Harris wrote on Saturday, March 7, 2015 11:50 :
>>> .
>>> .
>>> "The challenge I'm trying to solve is to provide a deterministic
>>> timekeeping
>>> and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) =
>>> 1972-01-01T00:00:10 (TAI). This is essentially the purpose of "civil time"
>>> timekeeping as is typically intended....The timescale before 1972 is an
>>> abstract proleptic Gregorian calendar scale for purposes of calculation
>>> convenience. On this scale, like NTP, PTP, and POSIX, any date-time before
>>> 1972-01-01T00:00:00Z (UTC) is considered either inaccurate or invalid."
>>>
>>> Civil timekeeping is concerned with many things, including determining when
>>> one date ends and another begins. Thus civil timekeeping is inextricably
>>> linked to civil calendars. Although the time of day of past events become
>>> less and less important as the decades pass, the date of those
>>> events remain
>>> important. Since some computer applications routinely attempt, in their
>>> clumsy way, to account for timezones, timekeeping is potentially important
>>> for the computer representation of timestamps, even when the humans using
>>> the computer are only interested in the date. Of course, dates long before
>>> 1972 are of interest in civil matters; dates of birth immediately come to
>>> mind.
>> I agree.
>>
>>> So when Brooks Harris presents his API to his stakeholders, I think a
>>> more thorough explanation of why date-time expressions before 1972
>>> will be "
>>> considered either inaccurate or invalid" will be needed.
>>
>> It is typically warned that date and time before 1972 cannot be
>> accurately represented with NTP or POSIX, for examples. These
>> timescale's origins precede 1972-01-01T00:00:00Z (UTC) =
>> 1972-01-01T00:00:10 (TAI) and seek to represent date-time counting
>> *forward*. They give no consideration to date-time accuracy before
>> 1972, but operate on proleptic scales convenient for computation.
>> This is generally true with widely available timekeeping services on
>> OSs, systems, languages, and many typical applications because so
>> many of them implement mechanisms based on the heritage of the POSIX
>> timekeeping mechanisms, complete with its flaws with respect to
>> representing UTC and Leap Seconds.
>>
>> In the discussions I've been involved with many people argued
>> strenuously "we don't care about the past, only accurate date-time
>> going forward!". The reason I'm choosing to ignore the subject of
>> accurate date-times before 1972 is not that its not important, but
>> probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
>> - its just too expansive a topic to tackle in some commonly accepted
>> way. For date-time before 1972 you've got to switch to some other
>> timescale depending on the purpose at hand.
>
> I figured it out the difference between GMD and UTC for POSIX. There
> was an 81 microsecond error, At the time, most UNIX boxes kept time to
> the nearest second, synchronized to a hairy wrist. There were advanced
> systems that could do milliseconds, and in the 1980s a few that had
> microsecond resolution, but we chained them to GPS via NTP, so the
> error was multiple milliseconds, depending on everything.
Keep in mind that time-stamps come from things other than computers. So while
this is an interesting footnote, it doesn?t describe the set of all timestamps. For
a general purpose API, it has to encompass more than what a computer was
capable of in the 70?s.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From imp at bsdimp.com Sun Mar 8 17:00:10 2015
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 8 Mar 2015 15:00:10 -0600
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FC77CA.8000205@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307185040843495.de5a6666@comcast.net>
<54FC77CA.8000205@edlmax.com>
Message-ID: <4B61EBDF-E2FE-4815-B698-55E15CDA761F@bsdimp.com>
> On Mar 8, 2015, at 10:24 AM, Brooks Harris wrote:
> I think the only way the industry can eventually converge on reliable "civil time" representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply "to kill Leap Seconds or not" they'd also have "a viable migration path to comprehensive UTC timekeeping implementation" to consider.
I think you vastly underestimate the amount of effort this change would entail. We?d trade
an off by 1 second every other year problem for an off by 36s problem in many different
places.
Even if we left time_t as a legacy thing, and defined a whole new set of interfaces that
did things pedantically correct, that?s a lot of effort to code and adopt. And there?s almost
no economic incentive to drive the change.
You?d need to change the ?It?s just a second, who cares?? attitude before meaningful
progress can be made in getting leap seconds right.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From brooks at edlmax.com Sun Mar 8 17:58:23 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 17:58:23 -0400
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <20150308194333.GZ8710@fysh.org>
References: <54EF28FD.9040404@meinberg.de>
<20150301133754927511.b6cf3588@comcast.net> <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
<20150308164500.GA14280@fysh.org> <54FC9BE6.9080301@edlmax.com>
<20150308194333.GZ8710@fysh.org>
Message-ID: <54FCC5FF.5050806@edlmax.com>
On 2015-03-08 03:43 PM, Zefram wrote:
> Brooks Harris wrote:
>> On 2015-03-08 12:45 PM, Zefram wrote:
>>> Brooks Harris wrote:
>>>> In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
>>>> = 10s.
>>> Where do you get this idea from? You've cited no source for it.
>>> You appear to have plucked it from thin air.
>> No, not from thin air, its very clear -
>>
>> IEEE Std 1588-2008, 7.2.3 UTC Offset - "...
>> timePropertiesDS.currentUtcOffset = TAI - UTC."... "NOTE-As of 0
>> hours 1 January 2006 UTC, UTC was behind TAI by 33 seconds."
> That clause does not specify a currentUtcOffset value for 1969-12-31.
> It gives a general definition, augmented with information that implies a
> currentUtcOffset value for 2006-01-01 (of 33 s). I'm really not seeing
> how you get from that to a value of 10 s for 1969-12-31. Taking UTC to
> include the rubber seconds era gives a varying non-integral value near 8 s
> for 1969-12-31.
That's what the explanations say, but not what real world
implementations do.
> Alternatively, your view that the pre-1972 history isn't
> `really' UTC implies that currentUtcOffset is undefined for 1969-12-31.
As a practical matter its most convenient use currentUtcOffset = 10s at
1970-01-01T00:00:00 (TAI) = "Zero PTP Time".
> Only your fictitious UTC gives currentUtcOffset = 10 s for 1969-12-31.
It not just my "fictitious UTC". That's how implementations are done.
When you do it that way its easy, and everything is OK after 1972.
> If you're trying to use this statement as justification for your time
> scale, then this is circular reasoning; you're begging the question.
>
>> Right. But like the "rubber-band era" they are beside the point of
>> timekeeping after 1972,
> They would be beside the point if you hadn't raised the issue yourself.
> You're expending a lot of effort on pre-1972 times that are all irrelevant
> for this purpose. The actual time of the NTP epoch is beside the point.
>
>> PTP's
>> epoch, 1970-01-01T00:00:00 (TAI) is explicit only if you extrapolate
>> proleptic TAI seconds prior to 1972-01-01 00:00:10 (TAI).
> 1972 is another date that doesn't mark the beginning of TAI. The name
> "TAI" arose in 1971, but the BIH had actually been operating the service
> in a pretty modern form for years. TAI times in 1970 are not proleptic.
Yes, I know.
>
>> RFC 5905, Figure 4: Interesting Historic NTP Dates, shows this.
>>
>> | 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
>> | 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC |
>>
>> Thats 2,272,060,800 absolute seconds offset from the NTP prime epoch
>> to 1972. 2272060800 / 86400 = 26297 exactly. There's no 10 second
>> remainder. An initial TAI-UTC 10s offset is in effect at 1972 (by
>> definition) so the seconds offset to the NTP prime epoch includes
>> this, that is, the initial TAI-UTC 10s is in effect at the beginning
>> of the NTP timescale.
> You have misinterpreted that table. The heading of the column you're
> referring to is "NTP Timestamp". There's no claim there that the
> 2272060800 is an actual number of seconds between two events. Rather,
> 2272060800 is the NTP scalar value describing 1972-01-01 00:00:00 UTC.
> As you have repeatedly pointed out, NTP doesn't count leap seconds.
> The difference between two NTP timestamps does not reflect the number
> of leap seconds that occurred in that interval. The 2272060800 value
> implies nothing at all about leap seconds between 1900 and 1972.
>
> Also note the next entry in the table:
>
> | 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th |
> | | | | | Century |
>
> This 3155587200 value is *also* an exact multiple of 86400. If it were
> to be interpreted as a pure count of seconds, it would imply that there
> were a total of zero leap seconds between 1900-01-01 and 1999-12-31, and
> similarly a total of zero leap seconds between 1972-01-01 and 1999-12-31.
> That would contradict the uncontroversial post-1972 leap second schedule.
No no no! NTP, and this table, do not address Leap Seconds at all.
That's the point of it! There are 3155587200 seconds from the epoch of
*that* particular NTP timescale that includes "31 Dec 1999" - its epoch
has slipped with respect to 1972UTC because the Leap Seconds are
unaccounted for. All NTP days are 86400 long, as you point out. When the
count freezes over a Leap Second the second offset to 1972UTC decreases
by one. That's the realization that hit me like a wave when I saw it.
There *are* zero leap seconds between [ 1900-01-01 *plus 22 forgotten
Leap Seconds* ] and 1999-12-31.
That's what David Wells is trying to point out - read that again
carefully -
David Wells writes:
The NTP Timescale and Leap Seconds
http://www.eecis.udel.edu/~mills/leap.html
3. How NTP and POSIX Reckon with Leap Seconds
"... the conversion is in effect reset to UTC as each broadcast timecode
is received. Thus, when a leap second is inserted in UTC and
subsequently in NTP or POSIX, knowledge of all previous leap seconds is
lost."
"Another way to describe this is to say there are as many NTP or POSIX
timescales as historic leap seconds. In effect, a new timescale is
reestablished after each new leap second. Thus, all previous leap
seconds, not to mention the apparent origin of the timescale itself,
lurch backward one second as each new timescale is established. ..."
>>> But the NTP epoch is not so well defined. The NTP epoch is
>>> not a specific point in time,
>> Sure it is. The *the prime epoch, or base date of era 0, is 0 h 1
>> January 1900 UTC"
> 1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
> extend back that far. The NTP epoch is, in that respect, fictitious.
Yes, of course. That's what NTP says, and that's what I'm saying. Its
proleptic, I think is the correct word. I find it curious the word
"proleptic" rarely appears in timekeeping specifications, when it is, in
fact, the proper word for some things being described.
I guess you could call it "fictitious" if you want. But it seems like
any numbering system is "fictitious" in that sense.
>
>> and is 2272060800 seconds before the "First day
>> UTC".
> And that's your misunderstanding of the NTP table again.
I don't think so.
-Brooks
>
> -zefram
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From brooks at edlmax.com Sun Mar 8 18:37:29 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Sun, 08 Mar 2015 18:37:29 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <4B61EBDF-E2FE-4815-B698-55E15CDA761F@bsdimp.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307185040843495.de5a6666@comcast.net>
<54FC77CA.8000205@edlmax.com>
<4B61EBDF-E2FE-4815-B698-55E15CDA761F@bsdimp.com>
Message-ID: <54FCCF29.7000803@edlmax.com>
On 2015-03-08 05:00 PM, Warner Losh wrote:
>> On Mar 8, 2015, at 10:24 AM, Brooks Harris wrote:
>> I think the only way the industry can eventually converge on reliable "civil time" representation is to refine the underlying time mechanisms in POSIX in some manner that allows a migration to a more comprehensive UTC implementation. I think if a new new POSIX time specification were to take shape it would add an option to the the conversation at ITU-R - instead of simply "to kill Leap Seconds or not" they'd also have "a viable migration path to comprehensive UTC timekeeping implementation" to consider.
> I think you vastly underestimate the amount of effort this change would entail.
Hi Warner,
Its a world-wide societal problem. I think it would take at least a
decade for a good specification to find its way into all main stream
systems and applications, and that's after it was agreed upon. I'd say
it can't be done, which I don't think that is underestimating it. But
never say never.
> We'd trade
> an off by 1 second every other year problem for an off by 36s problem in many different
> places.
>
> Even if we left time_t as a legacy thing,
I think you have to to provide reverse compatibility for an extended
transition period. I mean an *extended* transition period, like, until
all vestiges of the legacy implementations go offline. Even then, there
will be boat loads of archival timestamps created by the legacy systems.
> and defined a whole new set of interfaces that
> did things pedantically correct,
I think that's what's required.
> that's a lot of effort to code and adopt.
Oh, lots and lots and lots :-)
> And there's almost
> no economic incentive to drive the change.
I'm not sure that's true. The "dangers" of incorrect time stamps are
recognised in many quarters, not the least in financial and high-speed
trading. The possible catastrophic system failures are exactly where the
whole "kill Leap Seconds" thing comes from, where Google and others have
spent boat loads of energy and money to paper over the risk with Google
Smear. It seems to me like any and all players in the computer industry
would significantly benefit from real precision timekeeping. All
industries, jurisdictions, and citizens everywhere would benefit too.
Tons of money was spent on the "Y2K" problem. The "Leap Second" problem
is more subtle, but similar, and ubiquitous. There is not yet any
panicked demand for it, but there is building recognition of the issue.
The resources might still be mustered, especially behind a coherent and
credible design and plan.
>
> You'd need to change the "It's just a second, who cares?" attitude before meaningful
> progress can be made in getting leap seconds right.
There are an awful lot of people that recognize the problem and do care.
Will it coalesce into a movement? Only if a good plan emerges from
somewhere. Right now everybody just runs for cover...
-Brooks
>
> Warner
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From zefram at fysh.org Sun Mar 8 18:42:23 2015
From: zefram at fysh.org (Zefram)
Date: Sun, 8 Mar 2015 22:42:23 +0000
Subject: [LEAPSECS] My FOSDEM slides
In-Reply-To: <54FCC5FF.5050806@edlmax.com>
References: <54F6200A.7060906@meinberg.de>
<54F85C7B.5050508@meinberg.de> <54F8910E.7040004@edlmax.com>
<20150305182957.GU8710@fysh.org> <54F9FA4C.7060805@edlmax.com>
<20150308164500.GA14280@fysh.org> <54FC9BE6.9080301@edlmax.com>
<20150308194333.GZ8710@fysh.org> <54FCC5FF.5050806@edlmax.com>
Message-ID: <20150308224223.GA8710@fysh.org>
Brooks Harris wrote:
>As a practical matter its most convenient use currentUtcOffset = 10s
>at 1970-01-01T00:00:00 (TAI) = "Zero PTP Time".
So your entire justification for claiming this amounts to it being a
convenient fiction. Your reference to clauses of IEEE 1588 didn't add
anything to this argument.
>No no no! NTP, and this table, do not address Leap Seconds at all.
Right. That's why you can't infer any particular leap second history
from that table. Not for 1972 to 1999, and not for 1900 to 1972.
>There *are* zero leap seconds between [ 1900-01-01 *plus 22 forgotten
>Leap Seconds* ] and 1999-12-31.
If the leap seconds have been forgotten, how do you know how many
there were? Another part of the NTP spec is explicit about the notional
pre-1972 UTC having an unknown leap history.
Applying the view that NTP scalars are actual counts of seconds from
epochs that change at every leap second, the unknown notional leap seconds
between 1900 and 1972 impose an unknown slippage of epoch between the 1900
and 1972 entries in the table. The 1972 instant is 2272060800 seconds
from one of these epochs; there's no reason to suppose that that's the
same epoch as the one from which the 1900 instant is 0 s removed.
>On 2015-03-08 03:43 PM, Zefram wrote:
>>1900-01-01 00:00:00 UTC is a fictitious timestamp, because UTC doesn't
>>extend back that far. The NTP epoch is, in that respect, fictitious.
>
>Yes, of course. That's what NTP says, and that's what I'm saying. Its
>proleptic, I think is the correct word.
...
>I guess you could call it "fictitious" if you want. But it seems like
>any numbering system is "fictitious" in that sense.
There's a big difference between "proleptic" and "fictitious".
Applying the Gregorian calendar to the year 1415 is proleptic, because
the Gregorian calendar hadn't been invented at the time. But it's
not fictitious, because the Gregorian calendar serves perfectly well
to label specific days of that year. The Battle of Agincourt happened
on a day that the proleptic Gregorian calendar labels as "1415-11-03".
We can firmly link the modern label "1415-11-03" to the day that at the
time was referred to as "25 October 1415" (using the Julian calendar)
or as "Saint Crispin's Day".
The reference to "1900-01-01 00:00:00 UTC" is fictitious because the
mechanisms of UTC do not extend back that far. UTC cannot be used
to label specific instants in 1900. The label "1900-01-01 00:00:00
UTC" does not refer to a specific second that we could identify using
contemporaneous terminology, or for which we could identify historical
events.
>>And that's your misunderstanding of the NTP table again.
>
>I don't think so.
You haven't dissuaded me from this position. I don't quite grasp the
logic you're using, but it's clear that you're being inconsistent in how
you relate leap seconds to the table entries. Your entire rationale for
this leapless pre-1972 pseudo-UTC is based on your misinterpretation of
this clarifying table in the NTP spec.
-zefram
From dot at dotat.at Mon Mar 9 08:40:15 2015
From: dot at dotat.at (Tony Finch)
Date: Mon, 9 Mar 2015 12:40:15 +0000
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <54FC6D90.1070506@edlmax.com>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com>
Message-ID:
Brooks Harris wrote:
> On 2015-03-07 03:01 PM, Steve Allen wrote:
>
> > I would say that the intent NTP and POSIX is to correspond to civil
> > time in contemporary use. Therefore, for dates before 1972-01-01
> > NTP and POSIX are counting seconds of UT.
>
> This paragraph in your email had me scratching my head a little.
>
> I think none of the "civil" timescales are counting in UT - they are
> measured in SI Seconds, even when prolpetic to 1972.
>
> Am I missing something here?
POSIX time is defined by a mapping from broken-down civil time labels to a
scalar value. Currently civil time is UTC; in the past it was some other
variant of UT.
Tony.
--
f.anthony.n.finch http://dotat.at/
Southeast Biscay, Southeast Fitzroy: Variable 4. Rough. Fair. Good.
From brooks at edlmax.com Mon Mar 9 08:45:54 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Mon, 09 Mar 2015 08:45:54 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To:
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com>
Message-ID: <54FD9602.10400@edlmax.com>
On 2015-03-09 08:40 AM, Tony Finch wrote:
> Brooks Harris wrote:
>> On 2015-03-07 03:01 PM, Steve Allen wrote:
>>
>>> I would say that the intent NTP and POSIX is to correspond to civil
>>> time in contemporary use. Therefore, for dates before 1972-01-01
>>> NTP and POSIX are counting seconds of UT.
>> This paragraph in your email had me scratching my head a little.
>>
>> I think none of the "civil" timescales are counting in UT - they are
>> measured in SI Seconds, even when prolpetic to 1972.
>>
>> Am I missing something here?
> POSIX time is defined by a mapping from broken-down civil time labels to a
> scalar value. Currently civil time is UTC; in the past it was some other
> variant of UT.
Hi Tony,
So "UT" here is referring generally to the many variants of historical
"UT", including today's UTC. I see. Thanks.
-Brooks
>
> Tony.
From tvb at LeapSecond.com Mon Mar 9 14:10:39 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Mon, 9 Mar 2015 11:10:39 -0700
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com>
Message-ID: <284B08A259604194837B496FF75B366A@pc52>
> leap59 and leap61 are Leap Second announce signals, set 12 hours prior
> to the insert. There has been discussion about when the official
> announcements and expiration should be announced. ITU Rec 460 says
> "...at least eight weeks in advance". PTP can't do that, a point to keep
> in mind.
You've got to be kidding. Who on earth decided on only 12 hours notice? And 8 weeks is wrong too, for a different reason.
You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are given the actual future date of the leap second, as is done with GPS. You can get away with single warning bits too, as long as they apply to current month only, as is done with WWVB. Both of these are models on how to send out leap second notifications correctly. But allowing 8 weeks without a way to know which month it will occur in is wrong. For bit-only leap second warnings 4 weeks is the limit.
/tvb
From brooks at edlmax.com Mon Mar 9 15:53:30 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Mon, 09 Mar 2015 15:53:30 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <284B08A259604194837B496FF75B366A@pc52>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
Message-ID: <54FDFA3A.3050204@edlmax.com>
On 2015-03-09 02:10 PM, Tom Van Baak wrote:
>> leap59 and leap61 are Leap Second announce signals, set 12 hours prior
>> to the insert. There has been discussion about when the official
>> announcements and expiration should be announced. ITU Rec 460 says
>> "...at least eight weeks in advance". PTP can't do that, a point to keep
>> in mind.
Hi Tom,
> You've got to be kidding. Who on earth decided on only 12 hours notice?
IEEE 1588, I guess. Remember, 1588/PTP is intended primarily for
synchronization via "TAI-like" PTP Time over LAN networks. It requires
special switches supporting the various "Profiles" to have it work
correctly with high resolution. It can carry UTC metadata but it looks
all the world to me to have been a secondary consideration in the
design. You've seen some of my comments about how I think it's
definition of its epoch is flawed or misleading.
> And 8 weeks is wrong too, for a different reason.
That's in the primary document ITU-R Rec 460 we generally base part of
our "UTC specification" knowledge on, and the very document at the heart
of the "kill Leap Seconds" discussion. It says - "The IERS should decide
upon and announce the introduction of a leap-second, such an
announcement to be made at least eight weeks in advance.". This they
generally do as far as I know, as Bulletin C. I've never been able to
locate any official IERS policy that defines any schedule or rules about
when they will in fact issue Bulletin C.
>
> You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are given the actual future date of the leap second, as is done with GPS. You can get away with single warning bits too, as long as they apply to current month only, as is done with WWVB. Both of these are models on how to send out leap second notifications correctly.
Ah, well, "correctly" I guess - they can "work", but their promised
schedule is not the *same*.
> But allowing 8 weeks without a way to know which month it will occur in is wrong. For bit-only leap second warnings 4 weeks is the limit.
Many timekeeping systems seem to be designed for only indicating "now"
counting forward, including NTP, POSIX, and PTP, taking short-cuts to
avoid supplying full Leap Second and local-time metadata. I've never
been able to understand why that practice persists despite the obvious
need to be able to fully represent the entire post-1972 UTC timescale.
The policy and forms of the announce signals and Leap Seconds table are
obvious missing links, and its regrettable no official attempt has been
made since 1972 to rectify those inadequacies.
I think ITU-R will have no choice but to stay with current policies
because UTC with Leap Seconds is now too deeply embedded in timekeeping
legacy and can't realistically be excised. Their decision would be
easier if some credible proposal(s) had emerged, and its too bad the
"kill Leap Seconds" argument has diverted all attention and resources
from any effort to fix the situation. But I'd bet its still going to be
necessary.
-Brooks
>
> /tvb
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From sla at ucolick.org Tue Mar 10 10:36:00 2015
From: sla at ucolick.org (Steve Allen)
Date: Tue, 10 Mar 2015 07:36:00 -0700
Subject: [LEAPSECS] ITU-R CPM15-2
Message-ID: <20150310143600.GA6011@ucolick.org>
The deadline for contributions to the imminent second Conference
Prepatory Meeting for WRC-15 was yesterday.
http://www.itu.int/en/ITU-R/study-groups/rcpm/Pages/default.aspx
Among the contributions I see a bunch regarding Agenda Item 1.14
whose titles seem to seek to change the content of the existing
draft. Those are from
United States
Russia
UK
China
UAE, Algeria, Egypt, Jordan, Qatar, Sudan
Germany
I think this is an unprecedented level of active participation.
So it seems the CPM will be doing a lot of wordsmithing on
the document to be presented for a vote at WRC.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From sla at ucolick.org Wed Mar 11 09:44:50 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 11 Mar 2015 06:44:50 -0700
Subject: [LEAPSECS] Letters Blogatory
Message-ID: <20150311134450.GC31388@ucolick.org>
Ted Folkman is a lawyer who blogs about international law
https://lettersblogatory.com/2015/03/11/letters-blogatory-opposes-abolition-of-the-leap-second/#more-20126
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From brooks at edlmax.com Wed Mar 11 12:53:48 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Wed, 11 Mar 2015 12:53:48 -0400
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To: <20150311134450.GC31388@ucolick.org>
References: <20150311134450.GC31388@ucolick.org>
Message-ID: <5500731C.3080104@edlmax.com>
Overall he seems to make a good philosophical argument why solar time is
good for humans. But his conclusion seems confused.
"... let the airlines and the Internet companies use TAI".
Ah, the airlines already use GPS (TAI-like) for navigation, and "local
civil time" for scheduling, while the "internet companies" grapple with
TAI-like timescales, POSIX, and "local civil time" representations at
machine and human levels. There's atomic time and solar time and thats
the inconvenient truth that TAI v.s. UTC with Leap Seconds reconciles.
That's the whole point.
"In other words, let them simply stop adjusting for for leap seconds.
Let the atomic clocks become progressively more wrong."
Whoa! Hold the phone! What do you mean? Adjust TAI's frequency to match
Earth?!? Nobody anywhere is suggesting that! Of does he mean adjust the
count or labeling of TAI? Nobody's suggesting that either. That's what
UTC is.
"It seems to me we have our priorities backwards when we worry about how
to keep our everyday natural time in sync with our atomic clocks instead
of vice versa!"
Huh? I think he means the solar day ought to be the priority because its
more meaningful for humans, which I generally agree with. But this is an
argument to "keep Leap Seconds", not change TAI. He seems to have missed
the fact he himself makes earlier that there are two timescales.
Articles like that add confusion to the public discussion.
-Brooks
On 2015-03-11 09:44 AM, Steve Allen wrote:
> Ted Folkman is a lawyer who blogs about international law
>
> https://lettersblogatory.com/2015/03/11/letters-blogatory-opposes-abolition-of-the-leap-second/#more-20126
>
> --
> Steve Allen WGS-84 (GPS)
> UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
> 1156 High Street Voice: +1 831 459 3046 Lng -122.06015
> Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From tvb at LeapSecond.com Wed Mar 11 14:04:57 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 11 Mar 2015 11:04:57 -0700
Subject: [LEAPSECS] Letters Blogatory
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID:
Brooks,
> Overall he seems to make a good philosophical argument why solar time is
> good for humans. But his conclusion seems confused.
Quite correct. Solar time is good for humans. That's why no one except the United Kingdom can use UTC for their daily activities. Every other nation has a way to circumvent UTC and use their own local time instead.
UTC, with or without leap seconds, is still solar time -- plus or minus a couple of hours, plus or minus a couple billion people, plus or minus a thousand years. Noon at 12:00 is an extremely loose assumption.
I would not worry or argue what happens beyond 1,000 years or 10,000 years. Knowing what little I do about earth dynamics, and how science, technology, culture, and politics [d]evolves, it would be irresponsible for anyone in the year 2000 to dictate the details of atomic or civil time in the year 2500 or 3000.
>
> "... let the airlines and the Internet companies use TAI".
Ok, let's say the airplane runs on TAI. What about the pilot's watches? Their navigation iPads? Then what about ATC? Do you really want the plane running TAI and the tower running UTC? And just big planes but general aviation too? Crop dusters should also run TAI then? And not just one ATC tower but every tower in the world. What about collision avoidance systems? What about the employees of ATC. Should they use local time or UTC while the planes use TAI? What about the weather reports. Or emergency services? Or their wall clocks? Should the ticket reservation system run TAI then too? How about the entire airport ground infrastructure? Do you want fuel and baggage and security running a different timescale as ATC and pilots and planes? What about realtime telemetry? Or in-flight WiFi? Should all contracts involving the airplane industry be tied to TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "airline"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes transportation.
You can run through the same thought experiment for "internet companies". Do we want ATT to use TAI? All time-stamps going into and out of ATT are TAI. While Verizon uses UTC? What about Google? Or Microsoft? Should Facebook use TAI or UTC? Should local time be based on a hour offset from TAI then? Should all routers be required to use TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "internet company"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes the internet.
It sort of doesn't matter what that timescale is. Or where its midnight Meridian is historically located. It works extremely well to have one timescale for 99.9999% of human activity. Yes, there are some 0.0001% niche timescales for highly specific scientific purposes. But UTC runs the world. This must not change. Fortunately, neither the pro/con arguments for leap seconds propose a change in UTC's role in this regard. What is scary is when a lawyer jumps into the 15-year game and propose a third alternative: that certain major technology sectors of the planet switch to TAI, as a way to "solve" the leap second issue.
/tvb
From phk at phk.freebsd.dk Wed Mar 11 14:29:32 2015
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Wed, 11 Mar 2015 18:29:32 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To: <5500731C.3080104@edlmax.com>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID: <24804.1426098572@critter.freebsd.dk>
--------
In message <5500731C.3080104 at edlmax.com>, Brooks Harris writes:
>Overall he seems to make a good philosophical argument why solar time is
>good for humans. But his conclusion seems confused.
We have a saying in danish "Skoma'r bliv ved din l?st" which translates
to "Cobbler stay at your workbench".
The fact that he is a lawyer seems to have nothing, if anything to do
with his personal opinion on leap seconds.
In other words: Yeah, he's entitled to his opinion, just like everybody
else, but he doesn't have any special standing for his opinion, which as
others have pointed out, interfaces badly with reality.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From clive at davros.org Wed Mar 11 15:05:12 2015
From: clive at davros.org (Clive D.W. Feather)
Date: Wed, 11 Mar 2015 19:05:12 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To: <24804.1426098572@critter.freebsd.dk>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<24804.1426098572@critter.freebsd.dk>
Message-ID: <20150311190512.GA69762@davros.org>
Poul-Henning Kamp said:
> We have a saying in danish "Skoma'r bliv ved din l?st" which translates
> to "Cobbler stay at your workbench".
The English word is "last": "The cobbler should stick to his last". Almost
certainly with the same derivation.
> The fact that he is a lawyer seems to have nothing, if anything to do
> with his personal opinion on leap seconds.
>
> In other words: Yeah, he's entitled to his opinion, just like everybody
> else, but he doesn't have any special standing for his opinion, which as
> others have pointed out, interfaces badly with reality.
Exactly.
--
Clive D.W. Feather | If you lie to the compiler,
Email: clive at davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
From Kevin.Birth at qc.cuny.edu Wed Mar 11 14:59:28 2015
From: Kevin.Birth at qc.cuny.edu (Kevin Birth)
Date: Wed, 11 Mar 2015 18:59:28 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org>
<5500731C.3080104@edlmax.com>,
Message-ID:
Solar time is good for humans, but as everyone on this list knows, solar time is not the same as mean time or UTC.
>From a chronobiological perspective, mammals have a small cluster of neurons at the base of the hypothalamus called the suprachiasmatic nucleus (SCN). There are two parts to this structure. The medial portion has a robust free-running rhythm of around 24 hours plus or minus about 15 minutes. The two ventral portions connect to the optic nerve and have no strong rhythm. Instead, the ventral portions work to reset the dorsal part so that the @24 hour rhythm always anticipates the next sunrise regardless of seasonal variations in the length of the daylight period (or the equation of time). One could say that the SCN is an evolutionary adaptation to Earth's foibles.
The SCN then operates quite differently from representations of solar time, mean or apparent, which chart the rotational day. In fact, the SCN works much like some old forgotten systems of timekeeping like Bohemian or Italian time, which reset every day.
The features of UTC that we celebrate--continuity, uniformity and standardization--are features that are useful for measuring biological cycles but warp our understanding of those cycles if we begin to think of those cycles as having the same features of uniformity as UTC. This is true whether or not there are leap seconds. One of the shortcomings of modern chronobiology and psychophysics of time perception is that as they move more and more into laboratory settings from field settings the cycles are clock controlled, i.e., uniform. As a result, a lot of current biological science of timing is actually studying how well organisms adapt to humanly created time cycles rather than environmental cycles tied to the Earth's rotation and weather conditions.
Since many human activities are now structured by UTC and not circadian rhythms, many of those activities are, in fact, unhealthy. In a sense, with regard to what Folkman worries about in his blog, the horse has left the barn and galloped to the border, cleared customs, and now is in another country and most people still don't know the barn door is open much less the horse is gone. The disconnect between social rhythms, human biology, and apparent solar time began hundreds of years ago when preference in timekeeping shifted in favor of mean time and 24 hour days beginning at midnight, and this disconnect has been exacerbated by artificial lighting.
Cheers,
Kevin
________________________________________
From: LEAPSECS [leapsecs-bounces at leapsecond.com] on behalf of Tom Van Baak [tvb at LeapSecond.com]
Sent: Wednesday, March 11, 2015 2:04 PM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Letters Blogatory
Brooks,
> Overall he seems to make a good philosophical argument why solar time is
> good for humans. But his conclusion seems confused.
Quite correct. Solar time is good for humans. That's why no one except the United Kingdom can use UTC for their daily activities. Every other nation has a way to circumvent UTC and use their own local time instead.
UTC, with or without leap seconds, is still solar time -- plus or minus a couple of hours, plus or minus a couple billion people, plus or minus a thousand years. Noon at 12:00 is an extremely loose assumption.
I would not worry or argue what happens beyond 1,000 years or 10,000 years. Knowing what little I do about earth dynamics, and how science, technology, culture, and politics [d]evolves, it would be irresponsible for anyone in the year 2000 to dictate the details of atomic or civil time in the year 2500 or 3000.
>
> "... let the airlines and the Internet companies use TAI".
Ok, let's say the airplane runs on TAI. What about the pilot's watches? Their navigation iPads? Then what about ATC? Do you really want the plane running TAI and the tower running UTC? And just big planes but general aviation too? Crop dusters should also run TAI then? And not just one ATC tower but every tower in the world. What about collision avoidance systems? What about the employees of ATC. Should they use local time or UTC while the planes use TAI? What about the weather reports. Or emergency services? Or their wall clocks? Should the ticket reservation system run TAI then too? How about the entire airport ground infrastructure? Do you want fuel and baggage and security running a different timescale as ATC and pilots and planes? What about realtime telemetry? Or in-flight WiFi? Should all contracts involving the airplane industry be tied to TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "airline"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes transportation.
You can run through the same thought experiment for "internet companies". Do we want ATT to use TAI? All time-stamps going into and out of ATT are TAI. While Verizon uses UTC? What about Google? Or Microsoft? Should Facebook use TAI or UTC? Should local time be based on a hour offset from TAI then? Should all routers be required to use TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "internet company"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes the internet.
It sort of doesn't matter what that timescale is. Or where its midnight Meridian is historically located. It works extremely well to have one timescale for 99.9999% of human activity. Yes, there are some 0.0001% niche timescales for highly specific scientific purposes. But UTC runs the world. This must not change. Fortunately, neither the pro/con arguments for leap seconds propose a change in UTC's role in this regard. What is scary is when a lawyer jumps into the 15-year game and propose a third alternative: that certain major technology sectors of the planet switch to TAI, as a way to "solve" the leap second issue.
/tvb
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
From tvb at LeapSecond.com Wed Mar 11 16:53:20 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 11 Mar 2015 13:53:20 -0700
Subject: [LEAPSECS] Letters Blogatory
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>,
Message-ID:
Thanks, Kevin, for your interesting biological perspective. I think the two vocal astronomers on the mailing list, Rob and Steve, will be happy to add your conclusive scientific, .edu-validated, biological expertise to their pro- leap second knowledge base. As you know, I am neither pro or con, but as someone with many cesium clocks along with some mammals (wife, kids, dogs) in my home I wonder, though, if milliseconds per day (~2e-8) or milliseconds per day per century (~5e-13), have measurable effect on biological systems.
I always thought that biological systems were more resistant or more adaptive than parts per billion changes.
One could explore the effect of cross-continent seasonal migrations, or even cross-country college road-trips. An interesting experiment might be to change local time by an entire hour once or even twice a year and see how long or how quickly humans and domestic pets can adapt. The effect is non-zero. The "Q" value of that impulse would provide useful support to your conclusions. Or not. The other experiment is to go to Hawaii or Alaska for a week and see the effect that changes in latitude have on diurnal cycles. Having been to both in the past year, I can say it was quite profound and easily measurable at the 10% or maybe (with careful instrumentation and multiple runs by multiple people over many years) at the 1% level.
The issue of leap seconds, OTOH, is sort of at the 1e-8 to 1e-9 level. So I wonder if the biological effects you're talking about are perhaps a million times below noise?
/tvb
----- Original Message -----
From: "Kevin Birth"
To: "Tom Van Baak" ; "Leap Second Discussion List"
Sent: Wednesday, March 11, 2015 11:59 AM
Subject: RE: [LEAPSECS] Letters Blogatory
Solar time is good for humans, but as everyone on this list knows, solar time is not the same as mean time or UTC.
>From a chronobiological perspective, mammals have a small cluster of neurons at the base of the hypothalamus called the suprachiasmatic nucleus (SCN). There are two parts to this structure. The medial portion has a robust free-running rhythm of around 24 hours plus or minus about 15 minutes. The two ventral portions connect to the optic nerve and have no strong rhythm. Instead, the ventral portions work to reset the dorsal part so that the @24 hour rhythm always anticipates the next sunrise regardless of seasonal variations in the length of the daylight period (or the equation of time). One could say that the SCN is an evolutionary adaptation to Earth's foibles.
The SCN then operates quite differently from representations of solar time, mean or apparent, which chart the rotational day. In fact, the SCN works much like some old forgotten systems of timekeeping like Bohemian or Italian time, which reset every day.
The features of UTC that we celebrate--continuity, uniformity and standardization--are features that are useful for measuring biological cycles but warp our understanding of those cycles if we begin to think of those cycles as having the same features of uniformity as UTC. This is true whether or not there are leap seconds. One of the shortcomings of modern chronobiology and psychophysics of time perception is that as they move more and more into laboratory settings from field settings the cycles are clock controlled, i.e., uniform. As a result, a lot of current biological science of timing is actually studying how well organisms adapt to humanly created time cycles rather than environmental cycles tied to the Earth's rotation and weather conditions.
Since many human activities are now structured by UTC and not circadian rhythms, many of those activities are, in fact, unhealthy. In a sense, with regard to what Folkman worries about in his blog, the horse has left the barn and galloped to the border, cleared customs, and now is in another country and most people still don't know the barn door is open much less the horse is gone. The disconnect between social rhythms, human biology, and apparent solar time began hundreds of years ago when preference in timekeeping shifted in favor of mean time and 24 hour days beginning at midnight, and this disconnect has been exacerbated by artificial lighting.
Cheers,
Kevin
________________________________________
From: LEAPSECS [leapsecs-bounces at leapsecond.com] on behalf of Tom Van Baak [tvb at LeapSecond.com]
Sent: Wednesday, March 11, 2015 2:04 PM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Letters Blogatory
Brooks,
> Overall he seems to make a good philosophical argument why solar time is
> good for humans. But his conclusion seems confused.
Quite correct. Solar time is good for humans. That's why no one except the United Kingdom can use UTC for their daily activities. Every other nation has a way to circumvent UTC and use their own local time instead.
UTC, with or without leap seconds, is still solar time -- plus or minus a couple of hours, plus or minus a couple billion people, plus or minus a thousand years. Noon at 12:00 is an extremely loose assumption.
I would not worry or argue what happens beyond 1,000 years or 10,000 years. Knowing what little I do about earth dynamics, and how science, technology, culture, and politics [d]evolves, it would be irresponsible for anyone in the year 2000 to dictate the details of atomic or civil time in the year 2500 or 3000.
>
> "... let the airlines and the Internet companies use TAI".
Ok, let's say the airplane runs on TAI. What about the pilot's watches? Their navigation iPads? Then what about ATC? Do you really want the plane running TAI and the tower running UTC? And just big planes but general aviation too? Crop dusters should also run TAI then? And not just one ATC tower but every tower in the world. What about collision avoidance systems? What about the employees of ATC. Should they use local time or UTC while the planes use TAI? What about the weather reports. Or emergency services? Or their wall clocks? Should the ticket reservation system run TAI then too? How about the entire airport ground infrastructure? Do you want fuel and baggage and security running a different timescale as ATC and pilots and planes? What about realtime telemetry? Or in-flight WiFi? Should all contracts involving the airplane industry be tied to TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "airline"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes transportation.
You can run through the same thought experiment for "internet companies". Do we want ATT to use TAI? All time-stamps going into and out of ATT are TAI. While Verizon uses UTC? What about Google? Or Microsoft? Should Facebook use TAI or UTC? Should local time be based on a hour offset from TAI then? Should all routers be required to use TAI instead of UTC? Where does this lawyer draw the line? What is and isn't an "internet company"?
The entire purpose of UTC is to provide a single timescale for all human-related activity. That includes the internet.
It sort of doesn't matter what that timescale is. Or where its midnight Meridian is historically located. It works extremely well to have one timescale for 99.9999% of human activity. Yes, there are some 0.0001% niche timescales for highly specific scientific purposes. But UTC runs the world. This must not change. Fortunately, neither the pro/con arguments for leap seconds propose a change in UTC's role in this regard. What is scary is when a lawyer jumps into the 15-year game and propose a third alternative: that certain major technology sectors of the planet switch to TAI, as a way to "solve" the leap second issue.
/tvb
_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
From seaman at noao.edu Wed Mar 11 17:37:48 2015
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 11 Mar 2015 14:37:48 -0700
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To: <20150311190512.GA69762@davros.org>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<24804.1426098572@critter.freebsd.dk> <20150311190512.GA69762@davros.org>
Message-ID:
Clive D.W. Feather wrote:
>
> Poul-Henning Kamp said:
>> We have a saying in danish "Skoma'r bliv ved din l?st" which translates
>> to "Cobbler stay at your workbench".
>
> The English word is "last": "The cobbler should stick to his last". Almost
> certainly with the same derivation.
If you find yourself in Bucks County, Pennsylvania strongly consider visiting the Mercer Museum:
http://www.mercermuseum.org
A six story concrete castle built by two guys with a wheel barrow and a dog. In addition to several examples of cobbler?s lasts visitors can view vast numbers of artifacts from innumerable professions (including gallows and whaleboat). It?s across the street from James Michener?s Art Museum.
Sans traffic (as if) it?s under 2 hours from Queen?s College.
>> The fact that he is a lawyer seems to have nothing, if anything to do
>> with his personal opinion on leap seconds.
>>
>> In other words: Yeah, he's entitled to his opinion, just like everybody
>> else, but he doesn't have any special standing for his opinion, which as
>> others have pointed out, interfaces badly with reality.
>
> Exactly.
One imagines that many of the attendees of WRC-15 will be lawyers. Mr. Folkman has replied to the list on his blog.
Rob
From seaman at noao.edu Wed Mar 11 18:22:14 2015
From: seaman at noao.edu (Rob Seaman)
Date: Wed, 11 Mar 2015 15:22:14 -0700
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID: <21299DBC-F38A-4426-A19C-481C51C5B00A@noao.edu>
On Mar 11, 2015, at 11:04 AM, Tom Van Baak wrote:
> The entire purpose of UTC is to provide a single timescale for all human-related activity.
Well? ;-)
> Received: from barracuda-1.noao.edu ? Wed, 11 Mar 2015 11:05:10 -0700
> Received: from six.pairlist.net ... Wed, 11 Mar 2015 11:05:10 -0700 (MST)
>
> Received: from six.pairlist.net ... Wed, 11 Mar 2015 14:05:10 -0400 (EDT)
> Received: from jishnu.pair.com ... Wed, 11 Mar 2015 14:05:09 -0400 (EDT)
>
> Received: (qmail 2986 invoked by uid 3356); 11 Mar 2015 18:05:09 -0000
> Received: (qmail 2983 invoked from network); 11 Mar 2015 18:05:09 -0000
> Received: from mailwash27.pair.com ? 11 Mar 2015 18:05:09 -0000
>
> Received: from localhost ... Wed, 11 Mar 2015 14:05:09 -0400 (EDT)
> Received: from relay02.pair.com ... Wed, 11 Mar 2015 14:05:08 -0400 (EDT)
>
> Received: (qmail 66119 invoked by uid 0); 11 Mar 2015 18:05:06 -0000
> Received: from ? 11 Mar 2015 18:05:06 -0000
Intending to provide a single timescale is different from this being possible either across timezones, between mean time, local time, apparent time, sidereal time, for activities on Earth versus other planets, relativistically corrected, chrono-biologically calibrated, etc and so forth.
In particular, atomic timescales and solar timescales are simply two different things.
However, if you wish to eliminate leap seconds from some broad subset of timekeeping use cases, then call the resulting timescale something other than Coordinated Universal Time. Universal Time, coordinated or not, has always denoted a solar time scale. Debasing the meaning of Universal Time is unwarranted and unwise.
> I would not worry or argue what happens beyond 1,000 years or 10,000 years. Knowing what little I do about earth dynamics, and how science, technology, culture, and politics [d]evolves, it would be irresponsible for anyone in the year 2000 to dictate the details of atomic or civil time in the year 2500 or 3000.
Current usage is applied to both past and future timestamps. It would be irresponsible NOT to plan these details. Future lawyers might later arrange to change future standards, but current standards must be applicable for enduring purposes. (Angering the lawyers who do show up here in the mean time is a poor strategy ;-)
If the goal of redefining UTC is to render TAI (and presumably GPS) obsolete (?one timescale to rule them all?), one might suggest there are other ways to go about it without intruding on the solar concept of Universal Time in the first place.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rclark at noao.edu Wed Mar 11 18:39:43 2015
From: rclark at noao.edu (Richard Clark)
Date: Wed, 11 Mar 2015 15:39:43 -0700 (MST)
Subject: [LEAPSECS] Bio cycles and dueling timescales (was Letters Blogatory)
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>,
Message-ID:
I'm curious about the repeatability of natural biological cycles. I suspect
that most of them are actually triggered by external nonbiological cues
rather than being 'biological clocks' in our sense of the word clock.
Some that come to mind are annual. The swallows at Capistrano (and the
buzzards at Hinkley). I'm not sure how precisely repeatable they actually
are vs their popular representation.
But one that I have directly observed is the large bat colony under the
Campbell Ave bridge over the Rillito in Tucson. During June (Tucson
doesn't have weather in June) they come out en mass starting 7-9 minutes
after sunset. Very precisely, very repeatably. I imagine the cue is more
the illumination level than an internal clock. Also some sort of social
or aggrigate behavior may be involved. Later in the summer the mass exit
is more diffuse.
Some situations of humans adapting (or perhaps not adapting) to other day
lengths that come to mind, other than shift work in general, that come to
mind are the watch assignments on nuclear subs (repeats after 18 hours on
US subs) and mission control operators for the first few months of a newly
arived Mars lander (24h 39m). In the case of the Mars operators it's
tempting to try to actually adapt to the 24.65 hr day. There can even be
enough of them to form a group with some social identity, overlayed on
their home life. Talk about problems of where to draw the line between two
different timescales! The submariners actually are an isolated social
group but 18 hr isn't a period humans are likely able to adapt to.
What studies of these groups (and maybe South Pole winterovers too) have
there been?
Richard Clark
NSO/NISP
Tucson, Az.
On Wed, 11 Mar 2015, Kevin Birth wrote:
> Solar time is good for humans, but as everyone on this list knows, solar time is not the same as mean time or UTC.
>
> From a chronobiological perspective, mammals have a small cluster of neurons at the base of the hypothalamus called the suprachiasmatic nucleus (SCN). There are two parts to this structure. The medial portion has a robust free-running rhythm of around 24 hours plus or minus about 15 minutes. The two ventral portions connect to the optic nerve and have no strong rhythm. Instead, the ventral portions work to reset the dorsal part so that the @24 hour rhythm always anticipates the next sunrise regardless of seasonal variations in the length of the daylight period (or the equation of time). One could say that the SCN is an evolutionary adaptation to Earth's foibles.
>
> The SCN then operates quite differently from representations of solar time, mean or apparent, which chart the rotational day. In fact, the SCN works much like some old forgotten systems of timekeeping like Bohemian or Italian time, which reset every day.
>
> The features of UTC that we celebrate--continuity, uniformity and standardization--are features that are useful for measuring biological cycles but warp our understanding of those cycles if we begin to think of those cycles as having the same features of uniformity as UTC. This is true whether or not there are leap seconds. One of the shortcomings of modern chronobiology and psychophysics of time perception is that as they move more and more into laboratory settings from field settings the cycles are clock controlled, i.e., uniform. As a result, a lot of current biological science of timing is actually studying how well organisms adapt to humanly created time cycles rather than environmental cycles tied to the Earth's rotation and weather conditions.
>
> Since many human activities are now structured by UTC and not circadian rhythms, many of those activities are, in fact, unhealthy. In a sense, with regard to what Folkman worries about in his blog, the horse has left the barn and galloped to the border, cleared customs, and now is in another country and most people still don't know the barn door is open much less the horse is gone. The disconnect between social rhythms, human biology, and apparent solar time began hundreds of years ago when preference in timekeeping shifted in favor of mean time and 24 hour days beginning at midnight, and this disconnect has been exacerbated by artificial lighting.
>
> Cheers,
>
> Kevin
>
From clive at davros.org Wed Mar 11 19:30:05 2015
From: clive at davros.org (Clive D.W. Feather)
Date: Wed, 11 Mar 2015 23:30:05 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID: <20150311233005.GK29448@davros.org>
Tom Van Baak said:
> Quite correct. Solar time is good for humans. That's why no one except the United Kingdom can use UTC for their daily activities. Every other nation has a way to circumvent UTC and use their own local time instead.
That will come as a surprise to the inhabitants of Iceland, Ireland, Portugal,
and Greenland, to name the first four to come to mind.
--
Clive D.W. Feather | If you lie to the compiler,
Email: clive at davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
From tvb at LeapSecond.com Wed Mar 11 19:51:20 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 11 Mar 2015 16:51:20 -0700
Subject: [LEAPSECS] Letters Blogatory
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<21299DBC-F38A-4426-A19C-481C51C5B00A@noao.edu>
Message-ID:
Rob,
Yes, it looks to me like the timestamps you extracted below are all based on a global synchronized atomic time scale and solar time has nothing to do with it. Isn't it cool that all this works just fine, regardless of the current angle of the earth wrt the stars? And it would all continue to work if leap seconds were abandoned.
/tvb
----- Original Message -----
From: Rob Seaman
To: Leap Second Discussion List
Sent: Wednesday, March 11, 2015 3:22 PM
Subject: Re: [LEAPSECS] Letters Blogatory
On Mar 11, 2015, at 11:04 AM, Tom Van Baak wrote:
The entire purpose of UTC is to provide a single timescale for all human-related activity.
Well? ;-)
> Received: from barracuda-1.noao.edu ? Wed, 11 Mar 2015 11:05:10 -0700
> Received: from six.pairlist.net ... Wed, 11 Mar 2015 11:05:10 -0700 (MST)
> Received: from six.pairlist.net ... Wed, 11 Mar 2015 14:05:10 -0400 (EDT)
> Received: from jishnu.pair.com ... Wed, 11 Mar 2015 14:05:09 -0400 (EDT)
> Received: (qmail 2986 invoked by uid 3356); 11 Mar 2015 18:05:09 -0000
> Received: (qmail 2983 invoked from network); 11 Mar 2015 18:05:09 -0000
> Received: from mailwash27.pair.com ? 11 Mar 2015 18:05:09 -0000
> Received: from localhost ... Wed, 11 Mar 2015 14:05:09 -0400 (EDT)
> Received: from relay02.pair.com ... Wed, 11 Mar 2015 14:05:08 -0400 (EDT)
> Received: (qmail 66119 invoked by uid 0); 11 Mar 2015 18:05:06 -0000
> Received: from ? 11 Mar 2015 18:05:06 -0000
From sla at ucolick.org Thu Mar 12 01:21:43 2015
From: sla at ucolick.org (Steve Allen)
Date: Wed, 11 Mar 2015 22:21:43 -0700
Subject: [LEAPSECS] UTC fails
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID: <20150312052143.GA16547@ucolick.org>
On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
> The entire purpose of UTC is to provide a single timescale for all
> human-related activity.
And UTC has failed miserably. POSIX says UTC has no leaps.
Google says UTC has occasional days with stretches of seconds which
are of varying lengths. De facto, there is no single UTC time scale.
Unfortunately UTC was originally sold as the ultimate and complete
solution to two separate problems: seconds of uniform frequency and
mean solar time. As Rocket J. Squirrel said to Bullwinkle Moose
"That trick never works."
See a web snip from the recent European Postal & Telecom prep meeting
CPG15(15)024R1_Minutes_of_CPG15-6.docx
http://www.yme.gov.gr/getfile.php?id=5978
6.1.5 WRC-15 Agenda item 1.14 - Leap Second
Two opposing proposals for a New ECP on agenda item 1.14 which are
found in Annex 16 to CPG15(15)002, one based on Method A and the
other on Method C of the draft CPM text, have been introduced and
considered. No agreement could be reached and CPG15-6 tasked PTA
to continue its work.
France questioned whether the matter of the time scale should be
considered by the BIPM (International Bureau of Measurements and
Weight) instead of the ITU. Some Administrations stated that the
consequences of decision on this matter are quite important for
radio systems, in addition to the fact the ITU being a treaty
based organisation and BIPM is not.
The draft CEPT brief on AI 1.14 was approved and can be found in
Annex IV-15. CPG noted the draft ECPs.
Based on discussions at PTA, CPG considered editorial updates to
the draft CPM text and adopted the contribution to CPM15-2 (see
section 7).
"Statement by the Russian Federation:
The Russian Federation does not support CEPT contribution to CPM
on agenda item 1.14 as CEPT position on this issue is not defined
yet and that part of proposed modifications to the draft CPM
Report is premature. Moreover contribution includes reference to
the Workshop presentations which was not adopted through ITU-R
study process."
This snip lacks some of the referenced documents, and the UK is not
even mentioned in this summary, but it is clear: No consensus.
Elsewhere on the web are snips of other preparatory documents.
Almost violent discord. So much so that
when Dr. Matsakis opined that he would not want to be flying during a
leap second I pondered whether there are some folks so opposed that
they are planning to engineer a leap second catastrophe in order to
force the vote at WRC-15 in November.
But the bottom line for engineers who are implementing operational
systems that depend on timing is much simpler.
If you want to engage with a 15 year long international flame war
where people cannot agree on elapsed time to within several seconds,
then go ahead, choose the internationally-recommended UTC.
But if you want to get something working that does not get bothered by
differences of several nanoseconds, then ignore the international
recommendations and choose GPS time, Galileo, BeiDou, the Indian
satellite system time, or some PTP-based system via a device which
claims to be using one of those to supply TAI.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From tvb at LeapSecond.com Thu Mar 12 02:57:53 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Wed, 11 Mar 2015 23:57:53 -0700
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
Message-ID:
Brooks,
A couple more comments on your questions.
> Many timekeeping systems seem to be designed for only indicating "now"
> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
> avoid supplying full Leap Second and local-time metadata.
I'm not clear why you call that a "short-cut". It's just how clocks works. They tick forward and there is no requirement that they keep a record of time in the past. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC.
The only thing a UTC clock requires is advanced notice of the length of the current minute. This is required by no later than second 58 in the minute. But for practical reasons a UTC clock typically gets more notice than that, as you know.
> I've never
> been able to understand why that practice persists despite the obvious
> need to be able to fully represent the entire post-1972 UTC timescale.
> The policy and forms of the announce signals and Leap Seconds table are
> obvious missing links, and its regrettable no official attempt has been
> made since 1972 to rectify those inadequacies.
I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is "obvious".
A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed.
That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table.
By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC.
/tvb
From tvb at LeapSecond.com Thu Mar 12 03:45:29 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Thu, 12 Mar 2015 00:45:29 -0700
Subject: [LEAPSECS] UTC fails
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
Message-ID:
Steve,
> And UTC has failed miserably. POSIX says UTC has no leaps.
> Google says UTC has occasional days with stretches of seconds which
> are of varying lengths. De facto, there is no single UTC time scale.
Right! And many more examples of UTC fails -- the RTC of any unix computer. Any windows computer. Arduino and the microcontroller world. GPS receivers displaying 59 twice or 00 twice. IRIG. FAT (memory cards). Excel. eBay. Analog clocks.
It's getting increasingly awkward decade after decade to have all these holes in the practical implementation of UTC. Remember the paper that started all of this had "time to change" in the title:
http://gauss.gge.unb.ca/papers.pdf/gpsworld.november99.pdf
Remember also that in the 60's when leap seconds were conceived there were no personal computers, no quartz wrist watches, no internet, sailors used sextants or LORAN, WWV ticked on short-wave, teletypes were 110 baud, NASA used nixie tubes (no LED's), phones were black and rotary, you could dial in town with 4 digits, TV's had 3 channels, computers were the size of rooms and turned off at night, etc. Almost nobody knew about or was affected by leap seconds.
It was a reasonable technical solution for the era. I think those that want to get rid of leap seconds have a point; it is too awkward a universal solution for the 21st century.
> But the bottom line for engineers who are implementing operational
> systems that depend on timing is much simpler.
>
> If you want to engage with a 15 year long international flame war
> where people cannot agree on elapsed time to within several seconds,
> then go ahead, choose the internationally-recommended UTC.
>
> But if you want to get something working that does not get bothered by
> differences of several nanoseconds, then ignore the international
> recommendations and choose GPS time, Galileo, BeiDou, the Indian
> satellite system time, or some PTP-based system via a device which
> claims to be using one of those to supply TAI.
Good point. I agree. But its sad. And would have been unnecessary. This proliferation of timescales, even back in the late 90's, is the main reason (so I was told) that USNO proposed that leap seconds be re-considered. Dennis can provide more info if he's still on the list.
/tvb
From imp at bsdimp.com Thu Mar 12 08:04:24 2015
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 12 Mar 2015 21:04:24 +0900
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To:
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
Message-ID:
> On Mar 12, 2015, at 3:57 PM, Tom Van Baak wrote:
>
> Brooks,
>
> A couple more comments on your questions.
>
>> Many timekeeping systems seem to be designed for only indicating "now"
>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>> avoid supplying full Leap Second and local-time metadata.
>
> I'm not clear why you call that a "short-cut". It's just how clocks works. They tick forward and there is no requirement that they keep a record of time in the past. Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC.
>
> The only thing a UTC clock requires is advanced notice of the length of the current minute. This is required by no later than second 58 in the minute. But for practical reasons a UTC clock typically gets more notice than that, as you know.
>
>> I've never
>> been able to understand why that practice persists despite the obvious
>> need to be able to fully represent the entire post-1972 UTC timescale.
>> The policy and forms of the announce signals and Leap Seconds table are
>> obvious missing links, and its regrettable no official attempt has been
>> made since 1972 to rectify those inadequacies.
>
> I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is "obvious".
>
> A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed.
>
> That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table.
>
> By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC.
A clock doesn?t need to know its past. But a time scale is more than just how many seconds the current minute will have. It has a history and to compute elapsed time in that time scale, you need to know its history.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From Kevin.Birth at qc.cuny.edu Thu Mar 12 09:24:14 2015
From: Kevin.Birth at qc.cuny.edu (Kevin Birth)
Date: Thu, 12 Mar 2015 13:24:14 +0000
Subject: [LEAPSECS] Bio cycles and dueling timescales (was Letters
Blogatory)
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org>
<5500731C.3080104@edlmax.com>
Message-ID:
You are correct to not call biological cycles "clocks." Doing so is one
of my pet peeves, and I've recently published an article castigating the
psychophysics folks for doing so. The reference to that is:
Birth, Kevin. 2014. Non-clocklike Features of Psychological Timing and
Alternatives to the Clock Metaphor. Timing and Time Perception
2(3):312-324.
The bats, being mammals, have a SCN that is entrained by light/dark
cycles. The repetition in their daily cycles is due to the interaction of
the SCN's two parts--the free-running part with a @24 period, and a
photosensitive part that resets the free-running part daily. The
relationship of these two parts allow the bats to anticipate evening
twilight. Most likely there are hormonal rhythms that get them up and
going that start to kick in a hour or so before twilight. The reason why
they come out starting 7-9 minutes after sunset, despite seasonal
variability in daylight, is that the dorsal portion of the SCN is reset
each day (probably from a sunset cue), and then free-runs for @24 hours
until it is reset the next day. The same sort of mechanism (although
involving the pineal) is is also why roosters' crows anticipate the dawn
(I also have an article on roosters if you are interested). With roosters
I know that the hormone cycle that anticipates sunrise is a testosterone
cycle.
There is one study that I know about nuclear subs. Here is the reference:
Kelly, TL et al. 1999. Nonentrained circadian rhythms of melatonin in
sumbmariners scheduled to
an 18-hour day. Journal of Biological Rhythms, 14: 190-196.
The Martian day is probably within the range that some people could
entrain to it--the bigger problem would probably be bureaucrats insisting
that anyone on Mars live by a UTC day, which would have them feeling like
they had jetlag within about a week.
While I know several anthropologists who have worked in Antarctica, I
don't know any chronobiological studies done there. However, there is a
very interesting study of Eskimo that demonstrates that during the winter
months, they tend to experience day/night reversal of activity cycles
vis-a-vis UTC. That study is:
Stern, Pamela. 2003. Upside-Down and Backwards: Time Discipline in a
Canadian Inuit Town. Anthropologica 45:147-161.
I particularly like the Stern article because it demonstrates the tension
between what our bodies want to do and the rhythms structured by UTC + a
timezone offset. As I said in my earlier post, what worries me somewhat
is biology's uninformed adoption of UTC as if it accurate replicates
natural cycles of light and darkness.
Unfortunately, I'm less familiar with the literature on annual cycles than
I am on circadian cycles.
If you want any of the references I mentioned but cannot get them
yourself, I can probably find copies and send you .pdf files. If that is
the case, you should email me off the list--publishers are persnickety
about distribution of electronic copies on list-servs.
Cheers,
Kevin
Kevin K. Birth, Professor
Department of Anthropology
Queens College, City University of New York
65-30 Kissena Boulevard
Flushing, NY 11367
telephone: 718/997-5518
"We may live longer but we may be subject to peculiar contagion and
spiritual torpor or illiteracies of the imagination" --Wilson Harris
"Tempus est mundi instabilis motus, rerumque labentium cursus." --Hrabanus
Maurus
On 3/11/15 6:39 PM, "Richard Clark" wrote:
>I'm curious about the repeatability of natural biological cycles. I
>suspect
>that most of them are actually triggered by external nonbiological cues
>rather than being 'biological clocks' in our sense of the word clock.
>
>Some that come to mind are annual. The swallows at Capistrano (and the
>buzzards at Hinkley). I'm not sure how precisely repeatable they actually
>are vs their popular representation.
>
>But one that I have directly observed is the large bat colony under the
>Campbell Ave bridge over the Rillito in Tucson. During June (Tucson
>doesn't have weather in June) they come out en mass starting 7-9 minutes
>after sunset. Very precisely, very repeatably. I imagine the cue is more
>the illumination level than an internal clock. Also some sort of social
>or aggrigate behavior may be involved. Later in the summer the mass exit
>is more diffuse.
>
>Some situations of humans adapting (or perhaps not adapting) to other day
>lengths that come to mind, other than shift work in general, that come to
>mind are the watch assignments on nuclear subs (repeats after 18 hours on
>US subs) and mission control operators for the first few months of a newly
>arived Mars lander (24h 39m). In the case of the Mars operators it's
>tempting to try to actually adapt to the 24.65 hr day. There can even be
>enough of them to form a group with some social identity, overlayed on
>their home life. Talk about problems of where to draw the line between two
>different timescales! The submariners actually are an isolated social
>group but 18 hr isn't a period humans are likely able to adapt to.
>
>What studies of these groups (and maybe South Pole winterovers too) have
>there been?
>
>Richard Clark
>NSO/NISP
>Tucson, Az.
>
>
>On Wed, 11 Mar 2015, Kevin Birth wrote:
>
>> Solar time is good for humans, but as everyone on this list knows,
>>solar time is not the same as mean time or UTC.
>>
>> From a chronobiological perspective, mammals have a small cluster of
>>neurons at the base of the hypothalamus called the suprachiasmatic
>>nucleus (SCN). There are two parts to this structure. The medial
>>portion has a robust free-running rhythm of around 24 hours plus or
>>minus about 15 minutes. The two ventral portions connect to the optic
>>nerve and have no strong rhythm. Instead, the ventral portions work to
>>reset the dorsal part so that the @24 hour rhythm always anticipates the
>>next sunrise regardless of seasonal variations in the length of the
>>daylight period (or the equation of time). One could say that the SCN
>>is an evolutionary adaptation to Earth's foibles.
>>
>> The SCN then operates quite differently from representations of solar
>>time, mean or apparent, which chart the rotational day. In fact, the
>>SCN works much like some old forgotten systems of timekeeping like
>>Bohemian or Italian time, which reset every day.
>>
>> The features of UTC that we celebrate--continuity, uniformity and
>>standardization--are features that are useful for measuring biological
>>cycles but warp our understanding of those cycles if we begin to think
>>of those cycles as having the same features of uniformity as UTC. This
>>is true whether or not there are leap seconds. One of the shortcomings
>>of modern chronobiology and psychophysics of time perception is that as
>>they move more and more into laboratory settings from field settings the
>>cycles are clock controlled, i.e., uniform. As a result, a lot of
>>current biological science of timing is actually studying how well
>>organisms adapt to humanly created time cycles rather than environmental
>>cycles tied to the Earth's rotation and weather conditions.
>>
>> Since many human activities are now structured by UTC and not circadian
>>rhythms, many of those activities are, in fact, unhealthy. In a sense,
>>with regard to what Folkman worries about in his blog, the horse has
>>left the barn and galloped to the border, cleared customs, and now is in
>>another country and most people still don't know the barn door is open
>>much less the horse is gone. The disconnect between social rhythms,
>>human biology, and apparent solar time began hundreds of years ago when
>>preference in timekeeping shifted in favor of mean time and 24 hour days
>>beginning at midnight, and this disconnect has been exacerbated by
>>artificial lighting.
>>
>> Cheers,
>>
>> Kevin
>>
>_______________________________________________
>LEAPSECS mailing list
>LEAPSECS at leapsecond.com
>https://pairlist6.pair.net/mailman/listinfo/leapsecs
From Kevin.Birth at qc.cuny.edu Thu Mar 12 09:45:21 2015
From: Kevin.Birth at qc.cuny.edu (Kevin Birth)
Date: Thu, 12 Mar 2015 13:45:21 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org>
<5500731C.3080104@edlmax.com>
Message-ID:
My post was not to suggest that circadian cycles will be affected by leap
seconds or their absence as much as to point out that Mr. Folkman's
argument is a better argument against mean time than an argument in favor
of keeping the leap second.
Getting rid of the leap second will probably have no affect on circadian
biology. We already mess that up quite thoroughly with artificial lights
and UTC with leaps.
What getting rid of leap seconds will eventually do is create confusion in
the existing biological literature because biologists are generally not
attuned to the difference between clock time and environmental
cycles--they too often confuse the measure of time with the timing
phenomenon observed. So within a century, field primatologists might
start challenging the (silly) claim that baboons are active from 9 to 5.
The claim is silly because baboons do not tie their activity to clock
time, but cycles of daylight, but the literature emphasizes clock time.
As to the level of precision applicable to biological processes, since the
fastest neural processes are in milliseconds, for complex behaviors, like
response to a stimulus, we're probably talking about 10ths of seconds, but
this is only applicable to short-term timing mechanisms, not circadian
ones. The circadian system is remarkable for its ability to tolerate
changing periodicity of light due to weather and variation in Earth's
rotation.
With regard to cross-continental travel, there was a very interesting
study done on win/loss records of professional baseball teams on
cross-continental road trips. It actually matters. That study is:
RECHT, LAWRENCE, LEW, ROBERT A., SCHWARTZ, WILLIAM J. 1995. Baseball
teams beaten by jet lag. Nature 377:583
I do not know of any students that examine N/S travel across latitudes
during mid-winter or mid-summer.
Cheers,
Kevin
Kevin K. Birth, Professor
Department of Anthropology
Queens College, City University of New York
65-30 Kissena Boulevard
Flushing, NY 11367
telephone: 718/997-5518
"We may live longer but we may be subject to peculiar contagion and
spiritual torpor or illiteracies of the imagination" --Wilson Harris
"Tempus est mundi instabilis motus, rerumque labentium cursus." --Hrabanus
Maurus
On 3/11/15 4:53 PM, "Tom Van Baak" wrote:
>Thanks, Kevin, for your interesting biological perspective. I think the
>two vocal astronomers on the mailing list, Rob and Steve, will be happy
>to add your conclusive scientific, .edu-validated, biological expertise
>to their pro- leap second knowledge base. As you know, I am neither pro
>or con, but as someone with many cesium clocks along with some mammals
>(wife, kids, dogs) in my home I wonder, though, if milliseconds per day
>(~2e-8) or milliseconds per day per century (~5e-13), have measurable
>effect on biological systems.
>
>I always thought that biological systems were more resistant or more
>adaptive than parts per billion changes.
>
>One could explore the effect of cross-continent seasonal migrations, or
>even cross-country college road-trips. An interesting experiment might be
>to change local time by an entire hour once or even twice a year and see
>how long or how quickly humans and domestic pets can adapt. The effect is
>non-zero. The "Q" value of that impulse would provide useful support to
>your conclusions. Or not. The other experiment is to go to Hawaii or
>Alaska for a week and see the effect that changes in latitude have on
>diurnal cycles. Having been to both in the past year, I can say it was
>quite profound and easily measurable at the 10% or maybe (with careful
>instrumentation and multiple runs by multiple people over many years) at
>the 1% level.
>
>The issue of leap seconds, OTOH, is sort of at the 1e-8 to 1e-9 level. So
>I wonder if the biological effects you're talking about are perhaps a
>million times below noise?
>
>/tvb
>
>----- Original Message -----
>From: "Kevin Birth"
>To: "Tom Van Baak" ; "Leap Second Discussion List"
>
>Sent: Wednesday, March 11, 2015 11:59 AM
>Subject: RE: [LEAPSECS] Letters Blogatory
>
>
>Solar time is good for humans, but as everyone on this list knows, solar
>time is not the same as mean time or UTC.
>
>From a chronobiological perspective, mammals have a small cluster of
>neurons at the base of the hypothalamus called the suprachiasmatic
>nucleus (SCN). There are two parts to this structure. The medial
>portion has a robust free-running rhythm of around 24 hours plus or minus
>about 15 minutes. The two ventral portions connect to the optic nerve
>and have no strong rhythm. Instead, the ventral portions work to reset
>the dorsal part so that the @24 hour rhythm always anticipates the next
>sunrise regardless of seasonal variations in the length of the daylight
>period (or the equation of time). One could say that the SCN is an
>evolutionary adaptation to Earth's foibles.
>
>The SCN then operates quite differently from representations of solar
>time, mean or apparent, which chart the rotational day. In fact, the SCN
>works much like some old forgotten systems of timekeeping like Bohemian
>or Italian time, which reset every day.
>
>The features of UTC that we celebrate--continuity, uniformity and
>standardization--are features that are useful for measuring biological
>cycles but warp our understanding of those cycles if we begin to think of
>those cycles as having the same features of uniformity as UTC. This is
>true whether or not there are leap seconds. One of the shortcomings of
>modern chronobiology and psychophysics of time perception is that as they
>move more and more into laboratory settings from field settings the
>cycles are clock controlled, i.e., uniform. As a result, a lot of
>current biological science of timing is actually studying how well
>organisms adapt to humanly created time cycles rather than environmental
>cycles tied to the Earth's rotation and weather conditions.
>
>Since many human activities are now structured by UTC and not circadian
>rhythms, many of those activities are, in fact, unhealthy. In a sense,
>with regard to what Folkman worries about in his blog, the horse has left
>the barn and galloped to the border, cleared customs, and now is in
>another country and most people still don't know the barn door is open
>much less the horse is gone. The disconnect between social rhythms,
>human biology, and apparent solar time began hundreds of years ago when
>preference in timekeeping shifted in favor of mean time and 24 hour days
>beginning at midnight, and this disconnect has been exacerbated by
>artificial lighting.
>
>Cheers,
>
>Kevin
>
>
>
>
>
>
>
>________________________________________
>From: LEAPSECS [leapsecs-bounces at leapsecond.com] on behalf of Tom Van
>Baak [tvb at LeapSecond.com]
>Sent: Wednesday, March 11, 2015 2:04 PM
>To: Leap Second Discussion List
>Subject: Re: [LEAPSECS] Letters Blogatory
>
>Brooks,
>
>> Overall he seems to make a good philosophical argument why solar time is
>> good for humans. But his conclusion seems confused.
>
>Quite correct. Solar time is good for humans. That's why no one except
>the United Kingdom can use UTC for their daily activities. Every other
>nation has a way to circumvent UTC and use their own local time instead.
>
>UTC, with or without leap seconds, is still solar time -- plus or minus a
>couple of hours, plus or minus a couple billion people, plus or minus a
>thousand years. Noon at 12:00 is an extremely loose assumption.
>
>I would not worry or argue what happens beyond 1,000 years or 10,000
>years. Knowing what little I do about earth dynamics, and how science,
>technology, culture, and politics [d]evolves, it would be irresponsible
>for anyone in the year 2000 to dictate the details of atomic or civil
>time in the year 2500 or 3000.
>
>>
>> "... let the airlines and the Internet companies use TAI".
>
>Ok, let's say the airplane runs on TAI. What about the pilot's watches?
>Their navigation iPads? Then what about ATC? Do you really want the plane
>running TAI and the tower running UTC? And just big planes but general
>aviation too? Crop dusters should also run TAI then? And not just one ATC
>tower but every tower in the world. What about collision avoidance
>systems? What about the employees of ATC. Should they use local time or
>UTC while the planes use TAI? What about the weather reports. Or
>emergency services? Or their wall clocks? Should the ticket reservation
>system run TAI then too? How about the entire airport ground
>infrastructure? Do you want fuel and baggage and security running a
>different timescale as ATC and pilots and planes? What about realtime
>telemetry? Or in-flight WiFi? Should all contracts involving the airplane
>industry be tied to TAI instead of UTC? Where does this lawyer draw the
>line? What is and isn't an "airline"?
>
>The entire purpose of UTC is to provide a single timescale for all
>human-related activity. That includes transportation.
>
>You can run through the same thought experiment for "internet companies".
>Do we want ATT to use TAI? All time-stamps going into and out of ATT are
>TAI. While Verizon uses UTC? What about Google? Or Microsoft? Should
>Facebook use TAI or UTC? Should local time be based on a hour offset from
>TAI then? Should all routers be required to use TAI instead of UTC? Where
>does this lawyer draw the line? What is and isn't an "internet company"?
>
>The entire purpose of UTC is to provide a single timescale for all
>human-related activity. That includes the internet.
>
>It sort of doesn't matter what that timescale is. Or where its midnight
>Meridian is historically located. It works extremely well to have one
>timescale for 99.9999% of human activity. Yes, there are some 0.0001%
>niche timescales for highly specific scientific purposes. But UTC runs
>the world. This must not change. Fortunately, neither the pro/con
>arguments for leap seconds propose a change in UTC's role in this regard.
>What is scary is when a lawyer jumps into the 15-year game and propose a
>third alternative: that certain major technology sectors of the planet
>switch to TAI, as a way to "solve" the leap second issue.
>
>/tvb
>_______________________________________________
>LEAPSECS mailing list
>LEAPSECS at leapsecond.com
>https://pairlist6.pair.net/mailman/listinfo/leapsecs
>_______________________________________________
>LEAPSECS mailing list
>LEAPSECS at leapsecond.com
>https://pairlist6.pair.net/mailman/listinfo/leapsecs
From gwinn at raytheon.com Thu Mar 12 11:11:11 2015
From: gwinn at raytheon.com (Joseph M Gwinn)
Date: Thu, 12 Mar 2015 11:11:11 -0400
Subject: [LEAPSECS] UTC fails
In-Reply-To: <20150312052143.GA16547@ucolick.org>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
Message-ID:
Steve,
POSIX does not say that UTC has no leaps, it says that POSIX has no UTC
(despite the superficial similarity).
Joe Gwinn
From: Steve Allen
To: Leap Second Discussion List
Date: 03/12/2015 01:22 AM
Subject: [LEAPSECS] UTC fails
Sent by: "LEAPSECS"
On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
> The entire purpose of UTC is to provide a single timescale for all
> human-related activity.
And UTC has failed miserably. POSIX says UTC has no leaps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL:
From scolebourne at joda.org Thu Mar 12 11:57:26 2015
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 12 Mar 2015 15:57:26 +0000
Subject: [LEAPSECS] UTC fails
In-Reply-To: <20150312052143.GA16547@ucolick.org>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
Message-ID:
On 12 March 2015 at 05:21, Steve Allen wrote:
> On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
>> The entire purpose of UTC is to provide a single timescale for all
>> human-related activity.
>
> And UTC has failed miserably. POSIX says UTC has no leaps.
> Google says UTC has occasional days with stretches of seconds which
> are of varying lengths. De facto, there is no single UTC time scale.
But what so many miss is that what is needed to fix the problem is very small.
1) Reliably send leap second data out to the world (recently discussed
here and at tz-dist)
2) Announce leap seconds a bit further in advance or on a regular schedule
3) Define a time-scale, UT-86400, that roughly follows UTC but always
has 86400 "second-like" subdivisions (as per the Java time-scale)
4) Provide one or more *agreed* and *standardised* mechanisms to map
UTC to UT-86400 (eg. UTC-SLS and Google smear)
The fact that we don't have a name or agreed standard for the thing
that most people want (outside the time-nerd community) is very sad.
UT-86400 is a working name, I'm sure someone can think of a better
one.
The work needed isn't hard. I just wish that rather than destroying a
sensible solution to keep us in line with solar days, effort would be
put into defining the above.
Stephen
From brooks at edlmax.com Thu Mar 12 13:07:18 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Thu, 12 Mar 2015 13:07:18 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To:
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
Message-ID: <5501C7C6.9030801@edlmax.com>
Hi Tom,
On 2015-03-12 02:57 AM, Tom Van Baak wrote:
> Brooks,
>
> A couple more comments on your questions.
>
>> Many timekeeping systems seem to be designed for only indicating "now"
>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>> avoid supplying full Leap Second and local-time metadata.
> I'm not clear why you call that a "short-cut". It's just how clocks works.
Right, that's how a traditional clock works but that's fundamentally
inadequate when the UTC counting methods are in use. What I meant by
"short-cut" is that the UTC metadata (Leap Second announce and table)
are generally not provided or accounted for. NTP and POSIX drop the
23:59:60 count. They work like a traditional clock, not like a "UTC clock".
> They tick forward and there is no requirement that they keep a record of time in the past.
Right, Thats' the traditional concept of a clock. But we very much need
to calculate durations - "how long ago did an event happen?", "how long
was it between event A and event B?", "when is event A scheduled to occur?"
Traditionally, days were 86400 long, so calculating durations was
simple. Days are 86400 long in NTP and POSIX, so calculating durations
is simple BUT it doesn't match UTC! How many seconds between
1972-06-30T23:59:59Z (UTC) and 1972-01-01T00:00:00Z (UTC)? Two, not one,
because in NTP and POSIX 1972-06-30T23:59:60Z (UTC) went missing.
> Furthermore, any clock keeping UTC has no need for local time metadata. So you should not lump the tz mess into the simplicity of keeping UTC.
Right, well, typically the objective is to indicate "local civil time".
Only those jurisdictions at -00:00 offset from the UTC can use UTC, and
even then might observe Daylight. Humans care about "local civil time" -
only the timekeepers care about UTC who use it as the reference
timescale from which "local civil time" is derived. Yes, of course, the
whole topic of the tz mess is dragged into the calculation, which is
outside of UTC timekeeping discussion proper, but still required for
practical purpose of indicating "local civil time" and coordinating
activities by those time representations.
> The only thing a UTC clock requires is advanced notice of the length of the current minute.
In principle the announce could be even faster than that to keep
counting forward, but to schedule an event in the future you need either
the next upcoming Leap Second or how long in the future *we are sure*
there will not be a Leap Second.
> This is required by no later than second 58 in the minute.
Right.
> But for practical reasons a UTC clock typically gets more notice than that, as you know.
The more notice you have, the further in the future you can confidently
schedule, or predict.
Currently the announcements are essentially done by humans. ITU-R Rec
460 says "The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in
advance". That gives the humans at IERS time to create and publish
Bulletin C and presumably all the timekeeper humans enough time to
implement the upcoming Leap Second into their time servers or protocols.
IERS has done this "at least eight weeks in advance". The most recent
Bulletin C was issued nearly six months in advance. Note, however, its
not clear *exactly when* it was issued. I became aware of it like on Jan
2, but you'd really like to know *exactly* when it was issued.
Of course you'd really like to have this notification *automatically*
issued and taken up by all time servers, protocols, and applications
everywhere.
>> I've never
>> been able to understand why that practice persists despite the obvious
>> need to be able to fully represent the entire post-1972 UTC timescale.
>> The policy and forms of the announce signals and Leap Seconds table are
>> obvious missing links, and its regrettable no official attempt has been
>> made since 1972 to rectify those inadequacies.
> I don't know what you mean by represent the entire post-1972 timescale. Or why such a need is "obvious".
As Warner said in another LEAPSEECS post -
"A clock doesn?t need to know its past. But a time scale is more than
just how many seconds the current minute will have. It has a history and
to compute elapsed time in that time scale, you need to know its history."
You don't have a definition of what your clock means if you don't have a
specification of the timescale its representing. For the UTC timescale
you need the Leap Second metadata - all of it.
>
> A clock does not need to represent the infinite past, present, and future of a timescale. In the case of UTC the near future is unknowable anyway. The present is the requirement. And the past may or may not be a requirement depending on the user. Certainly a stand-alone RTC or time code generator or data logger or cesium clock keeping UTC does not need to know the past. So a historical table is not important. Only the leap second notification is needed.
>
> That's why the time codes you see broadcast, like WWVB or GPS only include a leap second notification and not a full table.
>
> By the way, the downside of WWVB's format is that it is not possible to obtain TAI. With GPS, at least, TAI is not only possible but easier and more reliable than UTC.
Long ago it was decided to disseminate time as UTC. This to maintain
continuity with the tradition of representing time as the "solar day",
or "mean solar day". I think that's the right approach, but the
specifications are unclear and incomplete, not to mention the "local
civil time" difficulties, which really overwhelms the TAI/UTC trouble as
far as accuracy is concerned.
If you have all the metadata (Leap Second announce, expiration, and
table) its easy to convert between UTC and TAI. With that you can
calculate accurate elapsed times and schedule as far in the future as
the upcoming Leap Second and expiration allow.
Conceptually you could think of UTC as really a dissemination of TAI,
but *encoded* with the "UTC counting method". But the broadcast UTC time
stamps don't have the metadata to make the conversion, so its incomplete
by itself, and there's no way to reliably, officially, and automatically
obtain the metadata.
Meantime there are the widely used NTP and POSIX timescales which are
obviously flawed in their counting of UTC, but these too can be
converted to TAI or UTC if the metadata is available.
Imagine BIPM, IERS, and ITU had originally done it the other way round -
disseminate TAI together with metadata to convert to UTC. Then you could
represent the timescales. But that's not what happened - they
distributed a UTC "clock", not the whole timescale.
In my opinion the central problem is the missing UTC Leap Second
metadata. Of course that by itself doesn't address the "local civil
time" challenge, but it would at least help eliminate the problems of UTC.
Simply "eliminating Leap Seconds" from the UTC time dissemination values
might help some faulty implementations from crashing or hanging, but it
could also evoke new unknown problems and bugs in other implementations.
By itself it doesn't eliminate the timekeeping difficulties in general.
It would only muddy the waters and disconnect us from the centuries old
tradition and goal of timekeeping by the Sun's position. From a
standard's point of view I think its just too dangerous to change the
procedures.
I think we're stuck with UTC, and UTU-R should add a forth option to
their agenda - go about defining a new modern way to distribute the
official UTC metadata.
-Brooks
>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From zefram at fysh.org Thu Mar 12 13:11:56 2015
From: zefram at fysh.org (Zefram)
Date: Thu, 12 Mar 2015 17:11:56 +0000
Subject: [LEAPSECS] Letters Blogatory
In-Reply-To: <5500731C.3080104@edlmax.com>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
Message-ID: <20150312171156.GB8710@fysh.org>
Brooks Harris wrote:
>"In other words, let them simply stop adjusting for for leap seconds.
>Let the atomic clocks become progressively more wrong."
>
>Whoa! Hold the phone! What do you mean? Adjust TAI's frequency to
>match Earth?!?
No, he's clearly proposing to leave TAI exactly as it is, and just to
use it in place of UTC for applications other than civil time. In his
view, "wrong" = "disagreeing with solar time". It's clear enough from
the sentences that you quoted, but it also refers back to the preceding
paragraph, in which he set up the view that the divergence between atomic
time and solar time means that one of them is getting "progressively
more wrong", and showed that he's not satisfied with viewing solar time
as the one that's wrong.
-zefram
From brooks at edlmax.com Thu Mar 12 13:51:05 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Thu, 12 Mar 2015 13:51:05 -0400
Subject: [LEAPSECS] UTC fails
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
Message-ID: <5501D209.9090707@edlmax.com>
On 2015-03-12 11:57 AM, Stephen Colebourne wrote:
> On 12 March 2015 at 05:21, Steve Allen wrote:
>> On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
>>> The entire purpose of UTC is to provide a single timescale for all
>>> human-related activity.
>> And UTC has failed miserably. POSIX says UTC has no leaps.
>> Google says UTC has occasional days with stretches of seconds which
>> are of varying lengths. De facto, there is no single UTC time scale.
> But what so many miss is that what is needed to fix the problem is very small.
>
> 1) Reliably send leap second data out to the world (recently discussed
> here and at tz-dist)
Yes. That's the crucial missing link.
> 2) Announce leap seconds a bit further in advance or on a regular schedule
Yes.
>
> 3) Define a time-scale, UT-86400, that roughly follows UTC but always
> has 86400 "second-like" subdivisions (as per the Java time-scale)
That's similar to NTP and POSIX. These timescales work just fine for
creating "broken down time" except for the 23:59:60th count (or rollover
at 23:59:58) and the fact their absolute seconds offset (time_t) does
not include the Leap Seconds.
>
> 4) Provide one or more *agreed* and *standardised* mechanisms to map
> UTC to UT-86400 (eg. UTC-SLS and Google smear)
Yes, but not to non-deterministic work-around things like Google Smear!
>
> The fact that we don't have a name or agreed standard for the thing
> that most people want (outside the time-nerd community) is very sad.
> UT-86400 is a working name, I'm sure someone can think of a better
> one.
Yes, in a way. The mismatch between UTC and the many timescales with
86400 second days one part of the the difficulties. There are many
"86400 second day" timescales that are not exactly the same (NTP and
POSIX, for examples) so there's already many potential names. We do have
the Gregorian calendar timescale, but this can't deal with Leap Seconds
by itself is related to each of the timescales in different ways. These
timescales exist and are in wide use so they can't be pulled back.
Gregorian, TAI, and UTC are the closest things to "common" you're going
to get.
>
> The work needed isn't hard. I just wish that rather than destroying a
> sensible solution to keep us in line with solar days, effort would be
> put into defining the above.
Conceptually not difficult depending on who you're talking to, but
arriving at consensus for standardization is a whole other matter. It
can be done, it needs to be done, but it won't be easy.
-Brooks
>
> Stephen
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>
From imp at bsdimp.com Thu Mar 12 16:04:13 2015
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 13 Mar 2015 05:04:13 +0900
Subject: [LEAPSECS] UTC fails
In-Reply-To:
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
Message-ID: <7A4B170A-68FE-4B64-9BD1-E4514FDB2E23@bsdimp.com>
> On Mar 13, 2015, at 12:57 AM, Stephen Colebourne wrote:
>
> On 12 March 2015 at 05:21, Steve Allen wrote:
>> On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
>>> The entire purpose of UTC is to provide a single timescale for all
>>> human-related activity.
>>
>> And UTC has failed miserably. POSIX says UTC has no leaps.
>> Google says UTC has occasional days with stretches of seconds which
>> are of varying lengths. De facto, there is no single UTC time scale.
>
> But what so many miss is that what is needed to fix the problem is very small.
Except that it isn?t.
> 1) Reliably send leap second data out to the world (recently discussed
> here and at tz-dist)
Doesn?t fix the POSIX time_t issue.
> 2) Announce leap seconds a bit further in advance or on a regular schedule
Ditto.
> 3) Define a time-scale, UT-86400, that roughly follows UTC but always
> has 86400 "second-like" subdivisions (as per the Java time-scale)
>
> 4) Provide one or more *agreed* and *standardised* mechanisms to map
> UTC to UT-86400 (eg. UTC-SLS and Google smear)
So UTC is great, except that we need to do this other thing that isn?t
UTC because UTC isn?t great? Seems like a lot of effort when dropping
leap seconds is a lot easier to implement.
> The fact that we don't have a name or agreed standard for the thing
> that most people want (outside the time-nerd community) is very sad.
> UT-86400 is a working name, I'm sure someone can think of a better
> one.
>
> The work needed isn't hard. I just wish that rather than destroying a
> sensible solution to keep us in line with solar days, effort would be
> put into defining the above.
So why is keeping us inline with solar days so desirable? The rate of
change is so slow and the number of people already out of sync with
solar time on the second level is so large it seems like a lot of hassle
for not much benefit when DUT1 can be known. Apart from telescopes,
nothing really breaks.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From seaman at noao.edu Thu Mar 12 19:48:06 2015
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 12 Mar 2015 16:48:06 -0700
Subject: [LEAPSECS] Universal Time works
In-Reply-To: <7A4B170A-68FE-4B64-9BD1-E4514FDB2E23@bsdimp.com>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
<7A4B170A-68FE-4B64-9BD1-E4514FDB2E23@bsdimp.com>
Message-ID: <5AE79BBE-70C6-468E-BCEC-9C2C65D0F5A2@noao.edu>
On Mar 12, 2015, at 1:04 PM, Warner Losh wrote:
> So why is keeping us inline with solar days so desirable? The rate of
> change is so slow and the number of people already out of sync with
> solar time on the second level is so large it seems like a lot of hassle
> for not much benefit when DUT1 can be known.
?Seems like a lot of hassle? is not a coherent engineering argument. Proponents of change to such a fundamental standard should quantify the trade-offs and risks before conducting a politicized vote. Few communities have been consulted even now.
> Apart from telescopes, nothing really breaks.
Even in astronomy this isn?t true:
http://www.cacr.caltech.edu/futureofutc/2011/preprints/36_AAS_11-677_Seaman.pdf
And the reason the American Astronautical Society sponsored two meetings on this topic is that there are serious concerns about the impact of redefining UTC on space operations. "The Space Community needs to develop a plan for upgrading operational software in case leap second discontinuance goes into effect?:
http://www.cacr.caltech.edu/futureofutc/2011/preprints/30_AAS_11-674_Storz.pdf
Perhaps the notion is that GNSS makes the obvious air, sea and land navigation issues obsolete, but GNSS itself would incur significant costs. "The costs and time needed for the required changes to the operational software and ICDs are unknown at this time, but they are expected to be significant?:
http://www.cacr.caltech.edu/futureofutc/2011/preprints/32_AAS_11-675_Malys.pdf
If a timescale is created without leap seconds it should be called something other than UTC, as discussed in Torino in 2003. This would preserve UTC (and the widespread concept of Universal Time as an approximation to mean solar time) for backwards compatibility. Many other issues are discussed in:
http://www.cacr.caltech.edu/futureofutc/2011/preprints/01_AAS_11-660.pdf
Rob Seaman
National Optical Astronomy Observatory
From imp at bsdimp.com Thu Mar 12 20:21:00 2015
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 13 Mar 2015 09:21:00 +0900
Subject: [LEAPSECS] Universal Time works
In-Reply-To: <5AE79BBE-70C6-468E-BCEC-9C2C65D0F5A2@noao.edu>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
<7A4B170A-68FE-4B64-9BD1-E4514FDB2E23@bsdimp.com>
<5AE79BBE-70C6-468E-BCEC-9C2C65D0F5A2@noao.edu>
Message-ID: <29B07A33-8A73-4D9D-A41F-89F08CB864BB@bsdimp.com>
> On Mar 13, 2015, at 8:48 AM, Rob Seaman wrote:
>
> On Mar 12, 2015, at 1:04 PM, Warner Losh wrote:
>
>> So why is keeping us inline with solar days so desirable? The rate of
>> change is so slow and the number of people already out of sync with
>> solar time on the second level is so large it seems like a lot of hassle
>> for not much benefit when DUT1 can be known.
>
> ?Seems like a lot of hassle? is not a coherent engineering argument. Proponents of change to such a fundamental standard should quantify the trade-offs and risks before conducting a politicized vote. Few communities have been consulted even now.
It is a perfectly valid engineering argument: The cost to do X is exceeded by the benefit.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
From seaman at noao.edu Thu Mar 12 21:37:51 2015
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 12 Mar 2015 18:37:51 -0700
Subject: [LEAPSECS] Universal Time works
In-Reply-To: <29B07A33-8A73-4D9D-A41F-89F08CB864BB@bsdimp.com>
References: <20150311134450.GC31388@ucolick.org> <5500731C.3080104@edlmax.com>
<20150312052143.GA16547@ucolick.org>
<7A4B170A-68FE-4B64-9BD1-E4514FDB2E23@bsdimp.com>
<5AE79BBE-70C6-468E-BCEC-9C2C65D0F5A2@noao.edu>
<29B07A33-8A73-4D9D-A41F-89F08CB864BB@bsdimp.com>
Message-ID: <89C914ED-F483-417F-89AD-3DF289296893@noao.edu>
On Mar 12, 2015, at 5:21 PM, Warner Losh wrote:
> It is a perfectly valid engineering argument: The cost to do X is exceeded by the benefit.
Neither the cost or the benefit have been quantified, nor the risks.
From tvb at LeapSecond.com Thu Mar 12 21:50:56 2015
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Thu, 12 Mar 2015 18:50:56 -0700
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
Message-ID: <836DE0B49C2E444EA175C3DCCB3E3861@pc52>
Brooks wrote:
>> Many timekeeping systems seem to be designed for only indicating "now"
>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>> avoid supplying full Leap Second and local-time metadata.
Warner wrote:
> A clock doesn?t need to know its past. But a time scale is more than just how
> many seconds the current minute will have. It has a history and to compute
> elapsed time in that time scale, you need to know its history.
Ok, thanks. So there's a terminology issue among Brooks' "timekeeping system", Tom's "clock", and Warner's "timescale".
I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a UTC synchronization algorithm. UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a timescale. There are clock ensemble algorithms. There are time transfer methods. There are time encoding conventions. There are time API's in languages, libraries, or operating systems.
WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST). GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO).
I'm not trying to pick a fight here. Just trying to seek clarification. I guess I still don't understand what Brooks is trying to "sell", or why full historical phase or frequency records are any part of timekeeping, or time transfer.
Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele? Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement?
I do a lot of timekeeping here, old and new. What time_t looked like before 1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an interest to me. But all the older stuff arrives in the form of faded paper, or JPG photos, or TXT files. I would never think of trying to encode that into some 32 or 64 bit binary format.
/tvb
From phk at phk.freebsd.dk Fri Mar 13 03:29:40 2015
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 13 Mar 2015 07:29:40 +0000
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <836DE0B49C2E444EA175C3DCCB3E3861@pc52>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
<836DE0B49C2E444EA175C3DCCB3E3861@pc52>
Message-ID: <28124.1426231780@critter.freebsd.dk>
--------
> I didn't think that NTP or POSIX or PTP is what we'd call a
> timescale. NTP is a UTC synchronization algorithm.
If we give the subword "scale" its usual meaning, then NTP is a
(also) a timescale: It carefully defines the scale on which it is
going to synchronize computer clocks, in particular it defines the
measurement unit on this scale to be 2^-32 SI second and the handling
of epoch roll-overs (every 2^32 SI seconds).
But more importantly, when we get to the point were we are arguing
over the meaning of common well known words we might as well stop it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
From brooks at edlmax.com Fri Mar 13 05:14:45 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Fri, 13 Mar 2015 05:14:45 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <836DE0B49C2E444EA175C3DCCB3E3861@pc52>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
<836DE0B49C2E444EA175C3DCCB3E3861@pc52>
Message-ID: <5502AA85.4090807@edlmax.com>
Hi Tom,
On 2015-03-12 09:50 PM, Tom Van Baak wrote:
> Brooks wrote:
>>> Many timekeeping systems seem to be designed for only indicating "now"
>>> counting forward, including NTP, POSIX, and PTP, taking short-cuts to
>>> avoid supplying full Leap Second and local-time metadata.
> Warner wrote:
>> A clock doesn?t need to know its past. But a time scale is more than just how
>> many seconds the current minute will have. It has a history and to compute
>> elapsed time in that time scale, you need to know its history.
> Ok, thanks. So there's a terminology issue among Brooks' "timekeeping system", Tom's "clock", and Warner's "timescale".
Oh yes, there sure are terminology issues all over the place. Its a
frustration of mine - expert debate endlessly about details to finally
discover they're talking about the same things in different term.
Timekeeping is old, there's lots of terms. Keeping thing clear is a
challenge.
>
> I didn't think that NTP or POSIX or PTP is what we'd call a timescale.
I do, I think.
I think of a timescale as having -
A) Some unit measure of time. Typically seconds, but could be some other
convenient division of time.
B) Some origin or "epoch" - a "starting point" for counting, might be
signed or unsigned.
C) Some "counting method" - as simple as uninterrupted incrementing
count, or more complex like Gregorian for example
"Counting method" deserves more explanation. I use the term to encompass
a couple concepts. A "counting method" could be a simple integer number
counting scheme (0,1,2,3,...) or generate a more complex encoding like
"1972-01-01T00:00:00". We've come to use the term "time related label" -
a lable being an 'identifier' assigned to some particular item in a
sequence of time-related units.
A "time related label" may be generated by the rules of *pure* Gregorian
calendar counting method -
1972-06-30T23:59:59
1972-07-01T00:00:00
Or Gregorian calendar modified by UTC Leap Seconds counting method -
1972-06-30T23:59:59
1972-06-30T23:59:60
1972-07-01T00:00:00
These might be represented as "broken down time" ie: YY-MM-DD hh:mm:ss
values.
There may be a corresponding absolute integer value for these seconds,
like time_t. Here the "counting method" is a zero-based uninterrupted
incrementing count, and each number is a "time related label" of each
second.
Put another way, the "counting method" is the algorithm by which the
time value is encoded as a time related label.
> NTP is a UTC synchronization algorithm.
Hmmm. Well, yes, I suppose. Hadn't thought of it that way.
If Leap Seconds are properly applied to it it effectively becomes many
independent timescales because the epoch slips with respect to
1972-01-01T00:00:00Z (UTC) with each Leap Second.
I think I'd say its an algorithm that synchronizes Gregorian calendar
date and time representations with UTC. Of course its obviously flawed
where the 23:59:60 count is concerned.
> UT0 is a measurement.
OK.
> UT1 is a timescale.
OK.
> TAI is a timescale.
Yes - a timescale with a simple counting method - an uninterrupted
incrementing count of seconds
> UTC is a timescale.
Yes - a timescale with a complex, irregular, and partly unpredictable
counting method.
> There are clock ensemble algorithms. There are time transfer methods. There are time encoding conventions. There are time API's in languages, libraries, or operating systems.
Sure, and its important to keep the divisions between what we're talking
about clear.
>
> WWVB is not a timescale. It is a time (and frequency) transfer service for UTC(NIST).
Yes, with a protocol for communicating the current UTC value along the
UTC timescale.
> GPS is not a timescale. It is a navigation positioning (and time transfer) service based on UTC(USNO).
Hmm. Right, well, GPS time is a timescale - time measure in seconds,
epoch at 1980-01-06T00:00:00Z (UTC), counting method of uninterrupted
weeks. While its epoch is referenced to UTC, its (primary) counting
method is "TAI-like" - uninterrupted regular count. It is GPS time on
the GPS timescale that is 'transferred', no?
>
> I'm not trying to pick a fight here. Just trying to seek clarification.
Thanks. I appreciate a productive conversation. The lexicon is always at
the root of the misunderstandings. This is critical when gets to
standards documents It has to be as clear and commonly understood as
possible and agreed on. That's part of the difficulty with UTC, other
timescales, and the whole subject of "time" - the documents are often
written is very different terms making understanding and comparisons
difficult.
> I guess I still don't understand what Brooks is trying to "sell", or why full historical phase or frequency records are any part of timekeeping, or time transfer.
To calculate accurate time intervals (durations) and/or elapsed times.
How many seconds between 1972-06-30T23:59:59Z (UTC) and
1972-07-01T00:00:00Z (UTC)? *Two*. But to know that you need to know a
positive Leap Second occured at 1972-06-30T23:59:60Z (UTC).
>
> Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further provide to satisfy your clientele?
It may not be practical to retrofit a metadata delivery channel into
those protocols. But we need a reliable electronic means of obtaining -
Leap Second announcements, "promised expiration", and the table of
historical Leap Seconds. Basically Bulletin C and
Leap_Second_History.dat
(https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat)
(Not just *my* clientele - any accurate UTC system.)
> Must you rely on hardcopy historical journal articles, on-air data, or web-based tables to satisfy your timekeeping requirement?
I'm talking about automatic electronic acquisition of the metadata, the
subject of recent postings about Rob Seaman's DNS scheme and Steve
Allan's use of the "right" tz database approach.
>
> I do a lot of timekeeping here, old and new. What time_t looked like before 1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an interest to me. But all the older stuff arrives in the form of faded paper, or JPG photos, or TXT files. I would never think of trying to encode that into some 32 or 64 bit binary format.
Date and time before 1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10
(TAI) is more-or-less inaccurate or controversial by any measure and
exist in eras when the names of timescales and historical values are
controversial. I know there are very good reasons for particular
purposes to represent date and times before the "UTC Leap Second Epoch",
but not for practical timekeeping after this epoch.
-Brooks
>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
From joegwinn at comcast.net Fri Mar 13 10:10:55 2015
From: joegwinn at comcast.net (Joseph Gwinn)
Date: Fri, 13 Mar 2015 10:10:55 -0400
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <836DE0B49C2E444EA175C3DCCB3E3861@pc52>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
<836DE0B49C2E444EA175C3DCCB3E3861@pc52>
Message-ID: <20150313101055480727.4ffbb441@comcast.net>
On Thu, 12 Mar 2015 18:50:56 -0700, Tom Van Baak wrote:
>
> I didn't think that NTP or POSIX or PTP is what we'd call a timescale.
As discussed in other responses, a timescale requires only three
things, a definition of zero time (or a specified time), a definition
of the "second" (or some other time duration unit), and a progression
rule. That's it.
By this definition, all three (NTP, POSIX, PTP) define private
timescales for their own internal use, and translate to and from
external timescales as needed.
> NTP is a UTC synchronization algorithm.
NTP is a synchronization algorithm for sure, but NTP is not limited to
UTC, even though the RFCs speak of UTC. Lots of people use NTP to
distribute GPS System Time, and I bet that there are people now using
NTP to distribute TAI.
> UT0 is a measurement. UT1 is a timescale. TAI is a timescale. UTC is a
timescale.
UT0 *is* a timescale, one that is tied to a specific astronomical
observatory. Multiple UT0 timescales are combined to yield UT1, and
UTC is derived from UT1.
Joe Gwinn
From sla at ucolick.org Fri Mar 13 10:29:25 2015
From: sla at ucolick.org (Steve Allen)
Date: Fri, 13 Mar 2015 07:29:25 -0700
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <28124.1426231780@critter.freebsd.dk>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com>
<284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
<836DE0B49C2E444EA175C3DCCB3E3861@pc52>
<28124.1426231780@critter.freebsd.dk>
Message-ID: <20150313142925.GA18505@ucolick.org>
On Fri 2015-03-13T07:29:40 +0000, Poul-Henning Kamp hath writ:
> But more importantly, when we get to the point were we are arguing
> over the meaning of common well known words we might as well stop it.
That's kindof funny because two weeks from now in Geneva at the
CPM15-2 meeting for Agenda Item 1.14 there are going to be a whole
bunch of delegations arguing over the meaning of "calendar day"
with some insisting that it is related to the rotation of the earth
and others denying the validity of the question.
--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
From rclark at noao.edu Fri Mar 13 16:10:09 2015
From: rclark at noao.edu (Richard Clark)
Date: Fri, 13 Mar 2015 13:10:09 -0700 (MST)
Subject: [LEAPSECS] Civil timekeeping before 1 January 1972
In-Reply-To: <836DE0B49C2E444EA175C3DCCB3E3861@pc52>
References: <000001d058f8$cdb74c60$6925e520$@comcast.net>
<54FB4DFF.3010106@edlmax.com> <20150307200111.GA24366@ucolick.org>
<54FC6D90.1070506@edlmax.com> <284B08A259604194837B496FF75B366A@pc52>
<54FDFA3A.3050204@edlmax.com>
<836DE0B49C2E444EA175C3DCCB3E3861@pc52>
Message-ID:
How fare back before 1972 do you want to go?
Before leap seconds, before TT, TDT, TAI. Entangled in the roots of
ET and Delta-T...
Back in the 70s and 80s there was considerable effort at JPL to improve
the models of orbital motion of the Galilean satelltes of Jupiter. The
existing theory, dating back to ~1915, was marginal for the pointing needs
of the high resolution cameras on Voyager and especially the more
demanding needs of the planned Galileo mission.
Among the data sources for developing and testing the new orbital models
were historical observations of satellite eclipses. Useable records of
several thousand historical observations going back as far as the mid
1600's have been recovered. But making use of these posed quite a problem
in converting the reported times to a modern form. Depending on the
source, the times might be expressed in apparent time, mean time, or
sidereal time.
Nothing specific to leap seconds here, just a little perspective for
thinking about the measurement and representation of time.
And for Tom van Baak--
About a month ago you relayed a question about computing the Equation of
Time to high accuracy. I mentioned that in the context of precision
ephemerides the EoT would be obtainable but usually would not be a
quantity of primary interest. Expanding an expression for EoT to higher
accuracy generally wasn't done. (of course that's not how I said it but
it's what I wanted to get across.) There is a proliferation of small cross
terms (not so much a slowness of convergence as I stated), and also below
the ~5 second level you start needing to consider the rate of change in
eccentricity of the Earth's orbit, apsidal and nodal precession, etc.
You need to reevaluate the coefficients of the angular terms, and the
angle offsets every decade or so.
Well, one of the papers that came out of this work at JPL shows a
counterexample!
Lieske, Astronomy & Astrophysics Supplement Series #63 (1986) pp 143-202
"A Collection of Galilean Satellite Eclipse Observations, 1652-1983"
Sections 3 & 4 discuss reduction of observed times to 'UT'. Used EoT,
delta-T, and mentions uncertainties in delta-T due to uncertainty in Lunar
acceleration.
Smart, "Textbook on Spherical Astronomy" shows how the EoT expansion
is developed.
Richard
NSO/NISP
Tucson, AZ
On Thu, 12 Mar 2015, Tom Van Baak wrote:
...
> I do a lot of timekeeping here, old and new. What time_t looked like
> before 1972 is not a problem. Yes, civil timekeeping (before or after
> 1972) is an interest to me. But all the older stuff arrives in the form
> of faded paper, or JPG photos, or TXT files. I would never think of
> trying to encode that into some 32 or 64 bit binary format.
>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
From seaman at noao.edu Fri Mar 20 18:31:35 2015
From: seaman at noao.edu (Rob Seaman)
Date: Fri, 20 Mar 2015 15:31:35 -0700
Subject: [LEAPSECS] Time and the Internet of Things...
Message-ID: <397B798D-FFFF-4956-BD34-B867E4B9B5CA@noao.edu>
I read slashdot so you don?t have to (you?re welcome):
NIST Technical Note 1867:
Time-Aware Applications, Computers, and Communication Systems (TAACCS)
http://dx.doi.org/10.6028/NIST.TN.1867
Kind of quiet around here lately; debating the implications of timekeeping in the IoT should cure that. UTC is mentioned three times in this document, TAI once and GPS/GNSS 26 times. No leap seconds per se. Any of the authors reading this?
Rob
From seaman at noao.edu Thu Mar 26 16:37:14 2015
From: seaman at noao.edu (Rob Seaman)
Date: Thu, 26 Mar 2015 13:37:14 -0700
Subject: [LEAPSECS] problem fetching Leap_Second_History.dat ?
Message-ID: <645782EA-FD50-4921-8293-4E24B80FFC39@noao.edu>
I can load this URL in a browser:
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
But PHK?s python code (which worked a couple of month?s ago):
def fetch_url(url):
global conn
print("Fetch", url)
if conn == None:
conn = httplib.HTTPConnection("hpiers.obspm.fr")
conn.request("GET", url)
r1 = conn.getresponse()
if r1.status != 200:
print (r1.status, r1.reason)
exit(2)
now throws an status:
302 Found
Which is a URL redirection (nominally ?moved temporarily?, which I saw yesterday evening in some browser or other). Not obvious if a failure to handle a redirection is the same as an error, but it seems possible that this is either a symptom of something else, or if actually a new layer of indirection in getting to this file will catch some other application.
Either way this may add more weight to the notion of using DNS instead of HTTP to fetch leap second info.
Haven?t looked very far under the hood yet, so could certainly be something else entirely.
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From hmurray at megapathdsl.net Fri Mar 27 01:51:26 2015
From: hmurray at megapathdsl.net (Hal Murray)
Date: Thu, 26 Mar 2015 22:51:26 -0700
Subject: [LEAPSECS] problem fetching Leap_Second_History.dat ?
Message-ID: <20150327055126.9F0C6406057@ip-64-139-1-69.sjc.megapath.net>
> http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
> Which is a URL redirection (nominally ?moved temporarily? ...
> Haven?t looked very far under the hood yet, so could certainly be something else entirely.
It redirects to
https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
(same with http=>https)
The S requires encryption. It's a lot more complicated so I'm not too
surprised that some software can't follow that redirection.
--
These are my opinions. I hate spam.
From brooks at edlmax.com Fri Mar 27 04:09:31 2015
From: brooks at edlmax.com (Brooks Harris)
Date: Fri, 27 Mar 2015 04:09:31 -0400
Subject: [LEAPSECS] problem fetching Leap_Second_History.dat ?
In-Reply-To: <645782EA-FD50-4921-8293-4E24B80FFC39@noao.edu>
References: <645782EA-FD50-4921-8293-4E24B80FFC39@noao.edu>
Message-ID: <5515103B.7080401@edlmax.com>
Hi Rob,
My Chrome browser opens with either.
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
I don't know Python much, but out of curiosity looked up http v.s.
https. Try calling class httplib.HTTPSConnection() instead of class
httplib.HTTPConnection() ?
-Brooks
On 2015-03-26 04:37 PM, Rob Seaman wrote:
> I can load this URL in a browser:
>
> http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
>
> But PHK's python code (which worked a couple of month's ago):
> def fetch_url(url):
> global conn
>
> print("Fetch", url)
> if conn == None:
> conn = httplib.HTTPConnection("hpiers.obspm.fr ")
> conn.request("GET", url)
> r1 = conn.getresponse()
> if r1.status != 200:
> print (r1.status, r1.reason)
> exit(2)
>
> now throws an status:
>
> 302 Found
>
> Which is a URL redirection (nominally "moved temporarily", which I saw
> yesterday evening in some browser or other). Not obvious if a failure
> to handle a redirection is the same as an error, but it seems possible
> that this is either a symptom of something else, or if actually a new
> layer of indirection in getting to this file will catch some other
> application.
>
> Either way this may add more weight to the notion of using DNS instead
> of HTTP to fetch leap second info.
>
> Haven't looked very far under the hood yet, so could certainly be
> something else entirely.
>
> Rob
>
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jhawk at MIT.EDU Fri Mar 27 11:54:10 2015
From: jhawk at MIT.EDU (John Hawkinson)
Date: Fri, 27 Mar 2015 11:54:10 -0400
Subject: [LEAPSECS] problem fetching Leap_Second_History.dat ?
In-Reply-To: <5515103B.7080401@edlmax.com>
References: <645782EA-FD50-4921-8293-4E24B80FFC39@noao.edu>
<5515103B.7080401@edlmax.com>
Message-ID: <20150327155410.GD922@mit.edu>
Brooks Harris wrote on Fri, 27 Mar 2015
at 04:09:31 -0400 in <5515103B.7080401 at edlmax.com>:
> I don't know Python much, but out of curiosity looked up http v.s.
> https. Try calling class httplib.HTTPSConnection() instead of class
> httplib.HTTPConnection() ?
I believe it should be using urllib not httplib. But I think PHK (and Rob)
can figure this out offline.
--jhawk at mit.edu
John Hawkinson