From magnus at rubidium.dyndns.org  Sat Oct  3 07:17:28 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 03 Oct 2009 13:17:28 +0200
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <21326.1254165579@critter.freebsd.dk>
References: <21326.1254165579@critter.freebsd.dk>
Message-ID: <4AC732C8.3060409@rubidium.dyndns.org>

Poul-Henning Kamp wrote:
> In message <1254164464.4ac107f0211cd at webmail.unb.ca>, "Richard B. Langley" writ
> es:
>> <http://gauss.gge.unb.ca/ITU_future_UTC_(CGSIC_49th).pdf>
> 
> Thanks.
> 
> Although I do appreciate what the context conveys, I did smile when I
> noticed that the last slide mentions "GPS time" but ends with
> "Only UTC can be disseminated".
> 
> I don't know if GPS or POSIX time is the most diseeminated timescale,
> but I suspect they both beat UTC by an order of magnitude when it comes
> to number of receivers...

Almost every GPS receiver also applies the UTC corrections to produce a 
UTC time. Infact, many of them can't externally produce any other time 
than UTC. Some has the ability to deliver GPS time or UTC time. Only a 
fraction of the receivers made only use GPS time, but then for some 
specific use.

So it is UTC and not GPS you should compare.

Cheers,
Magnus

From tvb at LeapSecond.com  Sat Oct  3 10:36:33 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Sat, 3 Oct 2009 07:36:33 -0700
Subject: [LEAPSECS] it's WP7A week in Geneva
References: <21326.1254165579@critter.freebsd.dk>
	<4AC732C8.3060409@rubidium.dyndns.org>
Message-ID: <EEAB047B79C84DEE917D4CEA32200A8A@pc52>

> Almost every GPS receiver also applies the UTC corrections to produce a 
> UTC time. Infact, many of them can't externally produce any other time 
> than UTC. Some has the ability to deliver GPS time or UTC time. Only a 
> fraction of the receivers made only use GPS time, but then for some 
> specific use.

It seems a lot of telecom applications use GPS time, avoiding
UTC altogether. Do you have any more information on this?

Your comments about GPS receivers and UTC need to include
the disclaimer. "after the receiver is powered up and after it has
achieved lock and after it has acquired the current UTC offset
from page 18 in subframe 4, which could be up to 12.5 minutes
later", then, yes, the GPS receiver will be able to produce UTC
reliably. But until that point, what the receiver actually produces
varies from model to model and also depends on how recently
the receiver was last used, etc.

/tvb


From imp at bsdimp.com  Sat Oct  3 12:23:07 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 03 Oct 2009 10:23:07 -0600 (MDT)
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <4AC732C8.3060409@rubidium.dyndns.org>
References: <21326.1254165579@critter.freebsd.dk>
	<4AC732C8.3060409@rubidium.dyndns.org>
Message-ID: <20091003.102307.-2117655735.imp@bsdimp.com>

In message: <4AC732C8.3060409 at rubidium.dyndns.org>
            Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: Poul-Henning Kamp wrote:
: > In message <1254164464.4ac107f0211cd at webmail.unb.ca>, "Richard B. Langley" writ
: > es:
: >> <http://gauss.gge.unb.ca/ITU_future_UTC_(CGSIC_49th).pdf>
: > 
: > Thanks.
: > 
: > Although I do appreciate what the context conveys, I did smile when I
: > noticed that the last slide mentions "GPS time" but ends with
: > "Only UTC can be disseminated".
: > 
: > I don't know if GPS or POSIX time is the most diseeminated timescale,
: > but I suspect they both beat UTC by an order of magnitude when it comes
: > to number of receivers...
: 
: Almost every GPS receiver also applies the UTC corrections to produce a 
: UTC time. Infact, many of them can't externally produce any other time 
: than UTC. Some has the ability to deliver GPS time or UTC time. Only a 
: fraction of the receivers made only use GPS time, but then for some 
: specific use.
: 
: So it is UTC and not GPS you should compare.

Ummm...  Every GPS receiver calculates GPS time.  Most are able to
produce UTC time.  But only after they "warm start" or after they get
the UTC offset from the almanac.  What they do before that is somewhat
ill defined on some, over defined on others.

Until they have this data, they can't start producing real UTC time.
12.5 minutes is the figure that's normally given for this.  If you
have a failure and have to swap in a new GPS receiver, you'll not have
UTC time for at least 12.5 minutes (usually more like 15-20 minutes
when all is said and done).  A 12.5 minute down time means your annual
reliability can only be 4 9's, not 5 9's...  This is why many
receivers remember the last UTC offset values and warm start with them
if they have only been off a short period of time...

Warner

From tvb at LeapSecond.com  Sat Oct  3 15:23:14 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Sat, 3 Oct 2009 12:23:14 -0700
Subject: [LEAPSECS] it's WP7A week in Geneva
References: <21326.1254165579@critter.freebsd.dk><4AC732C8.3060409@rubidium.dyndns.org>
	<20091003.102307.-2117655735.imp@bsdimp.com>
Message-ID: <AA4DC229FEB6434B988E17561955B4D1@pc52>

> when all is said and done).  A 12.5 minute down time means your annual
> reliability can only be 4 9's, not 5 9's...  This is why many
> receivers remember the last UTC offset values and warm start with them
> if they have only been off a short period of time...
> 
> Warner

Yes, but you know this only partly solves the problem; it might
even make it worse depending on how rigorous your testing
needs to be.

Now you have a battery- or EEPROM-based GPS receiver that
either 1) produces UTC correctly right away, or 2) produces a
UTC that's off by one second right away -- and somewhere in
the next 12.5 minutes later it spontaneously corrects itself and
produces UTC correctly.

User code can usually handle being told by a GPS receiver
that "UTC is not known yet; use GPS time instead". But when
a GPS receiver says "sorry, by the way, all the UTC time stamps
I've sent you in the past quarter hour were off by one second",
that might be a little more trouble to deal with.

The receiver has to define what a "short time" is or perhaps
more accurately, when in time that short time is. For example,
caching the leap second offset will be fine if that short time is
in October but not if it's near the end of December. Caching
all of dTls, dTlsf, WNt, WNlsf might take care of that. But then
you also have to consider 256-week issues:
http://www.leapsecond.com/notes/leapsec256.htm

/tvb


From seaman at noao.edu  Sat Oct  3 17:56:17 2009
From: seaman at noao.edu (Rob Seaman)
Date: Sat, 3 Oct 2009 14:56:17 -0700
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: <AA4DC229FEB6434B988E17561955B4D1@pc52>
References: <21326.1254165579@critter.freebsd.dk><4AC732C8.3060409@rubidium.dyndns.org>
	<20091003.102307.-2117655735.imp@bsdimp.com>
	<AA4DC229FEB6434B988E17561955B4D1@pc52>
Message-ID: <0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>

Tom Van Baak wrote:

>> when all is said and done).  A 12.5 minute down time means your  
>> annual reliability can only be 4 9's, not 5 9's...  This is why  
>> many receivers remember the last UTC offset values and warm start  
>> with them if they have only been off a short period of time...
>> Warner
>
> User code can usually handle being told by a GPS receiver that "UTC  
> is not known yet; use GPS time instead". But when a GPS receiver  
> says "sorry, by the way, all the UTC time stamps
> I've sent you in the past quarter hour were off by one second", that  
> might be a little more trouble to deal with.

Could somebody comment on the reliability of GPS receivers to deliver  
GPS time itself?

It is clearly aberrant design for any system to ever lie about a  
return value.  This is why error handling exists.  There are any  
number of quite desirable reasons a specific model of GPS receiver  
might be designed to behave idiosyncratically.  If there is no  
separate channel to convey errors properly, then it should at least  
return a non-legal value (-1 or such) pending this 12.5 minute start- 
up interval.  The three behavioral issues (choice of timescale,  
potentially lengthy initialization procedure, proper error handling)  
are orthogonal.

That said, client applications often have to deal with less than  
perfect hardware or software components.  In this case it sounds like  
the app (or a system like NTP) would be wise to manage restarts by  
marking a restarting receiver as invalid for 12.5 minutes (or until  
some other condition is met).  I'm sure I'm about to hear why this is  
a naive statement :-)

However, is it a true assertion that currently deployed GPS receivers  
return GPS time significantly more reliably (all those 9's) than they  
do UTC?  (Assuming a particular model supports both?)

It's hard to see this as supporting a position that "Only UTC can be  
disseminated"...

Rob



From phk at phk.freebsd.dk  Sat Oct  3 18:45:14 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 03 Oct 2009 22:45:14 +0000
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: Your message of "Sat, 03 Oct 2009 14:56:17 MST."
	<0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu> 
Message-ID: <33150.1254609914@critter.freebsd.dk>

In message <0B8B21EB-DBEA-4DEC-89C5-F27557F37495 at noao.edu>, Rob Seaman writes:
>Tom Van Baak wrote:

>It is clearly aberrant design for any system to ever lie about a  
>return value.

Well, "lie" is such a strong word.

I know for sure that both the Motorola UT+ and M12+T in certain a
certain specific situation will indicate that it delivers UTC
timestamps but in fact the receiver does not have sufficient
information to adjust from the GPS to the UTC timescale.

The exact circumstances are very specific and related to Almanac
data confusions in conjunction with short interruptions of power.

The timestamps delivered are often, but not always GPS timestamps
in this particular case.

I am not aware if Motorola has fixed this in later firmware revisions.

Poul-Henning

-- 
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 magnus at rubidium.dyndns.org  Sun Oct  4 06:49:06 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 04 Oct 2009 12:49:06 +0200
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <EEAB047B79C84DEE917D4CEA32200A8A@pc52>
References: <21326.1254165579@critter.freebsd.dk>	<4AC732C8.3060409@rubidium.dyndns.org>
	<EEAB047B79C84DEE917D4CEA32200A8A@pc52>
Message-ID: <4AC87DA2.4040103@rubidium.dyndns.org>

Tom Van Baak wrote:
>> Almost every GPS receiver also applies the UTC corrections to produce 
>> a UTC time. Infact, many of them can't externally produce any other 
>> time than UTC. Some has the ability to deliver GPS time or UTC time. 
>> Only a fraction of the receivers made only use GPS time, but then for 
>> some specific use.
> 
> It seems a lot of telecom applications use GPS time, avoiding
> UTC altogether. Do you have any more information on this?

To the best of my knowledge that is very rare. Few GPS clocks I have 
seen uses their own GPS receiver. I can ask around.

> Your comments about GPS receivers and UTC need to include
> the disclaimer. "after the receiver is powered up and after it has
> achieved lock and after it has acquired the current UTC offset
> from page 18 in subframe 4, which could be up to 12.5 minutes
> later", then, yes, the GPS receiver will be able to produce UTC
> reliably. But until that point, what the receiver actually produces
> varies from model to model and also depends on how recently
> the receiver was last used, etc.
> 

My point was that most receivers can only output UTC time rather than 
UTC or GPS time, even if it has knowledge of both time scales. The 
navigation core uses GPS time, but ECEF coordinates gets converted into 
normal long, lat, height and UTC. Additional settings can adjust to 
local datums such as RT90 and UTC+1h/UTC+2h-

Of course it cannot output a correct UTC solution until it has received 
page 18 subframe 4, but it can store the leapsecond offset in 
non-volatile RAM since last lock and for most of times that would give 
correct UTC from first lock. How many if any receiver uses that, I do 
not know, but it is technically possible, just as you store the almenac 
data and last known position in order to accelerate those first 12,5 
min. Recall, for this strategy to fail, the receiver must have been 
turned off over a leap-second event. Most times it is turned off is not 
a leap-second event.

Cheers,
Magnus

From phk at phk.freebsd.dk  Sun Oct  4 07:15:15 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 04 Oct 2009 11:15:15 +0000
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: Your message of "Sun, 04 Oct 2009 12:49:06 +0200."
	<4AC87DA2.4040103@rubidium.dyndns.org> 
Message-ID: <58209.1254654915@critter.freebsd.dk>

In message <4AC87DA2.4040103 at rubidium.dyndns.org>, Magnus Danielson writes:

>Of course it cannot output a correct UTC solution until it has received 
>page 18 subframe 4, but it can store the leapsecond offset in 
>non-volatile RAM since last lock and for most of times that would give 
>correct UTC from first lock [...]

And once again, this topic reminds me of my favourite Monty Python
episode:

	"This is an official announcement from the Royal Navy.

	Canibalism is a problem the Royal Navy has mostly under control.

	[...]
	"

"most of the times" is simply not good enough.

-- 
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 magnus at rubidium.dyndns.org  Sun Oct  4 07:24:42 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 04 Oct 2009 13:24:42 +0200
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: <0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>
References: <21326.1254165579@critter.freebsd.dk><4AC732C8.3060409@rubidium.dyndns.org>	<20091003.102307.-2117655735.imp@bsdimp.com>	<AA4DC229FEB6434B988E17561955B4D1@pc52>
	<0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>
Message-ID: <4AC885FA.9040706@rubidium.dyndns.org>

Rob Seaman wrote:
> Tom Van Baak wrote:
> 
>>> when all is said and done).  A 12.5 minute down time means your 
>>> annual reliability can only be 4 9's, not 5 9's...  This is why many 
>>> receivers remember the last UTC offset values and warm start with 
>>> them if they have only been off a short period of time...
>>> Warner
>>
>> User code can usually handle being told by a GPS receiver that "UTC is 
>> not known yet; use GPS time instead". But when a GPS receiver says 
>> "sorry, by the way, all the UTC time stamps
>> I've sent you in the past quarter hour were off by one second", that 
>> might be a little more trouble to deal with.
> 
> Could somebody comment on the reliability of GPS receivers to deliver 
> GPS time itself?

On the first fix it has resolved GPS time, modulus the 1024 week 
wrapping. The receiver itself rarely needs GPS time as a compound unit, 
but it remains broken down to GPS week, Z-count (1,5 sec tick wrapping 
on new GPS week), and then some suitable high-rate counter. The 
individual channels build their own 1,023 MHz or 10,23 MHz counters 
(with doppler), 1 ms counter, 20 ms counter (for data bit alignment),
page and frame counters etc being synchronous to the receiver. The 
common high-rate clock is used to sample the phase state of the channels 
, pseudo-ranges is built, processed and out comes the ECEF results 
[XYZT]. Time-errors is adjusted according to some suitable algoritm, but 
occasional jumps is seen in the data for some receivers. See Misra&Enge 
for examples of that. A lot of the processing uses various forms of 
issue of data to give corrections to orbit parameters for instance. So 
broken up GPS time is in the very core of things. But cranking out date 
and time isn't, it's an adaptation to the user.

We have had issues where GPS time has not been reliable due to incorrect 
handing of the 1024 week wrapping. The produced UTC time as affected as 
a side consequence. If the receivers where using L2C they would be able 
to resolve this from the signal, as it has a 8192 week wrapping. Some 
early receivers used a bias scheme and in one case it processed the GPS 
week like this:

if (GPSweek < 500)
	GPSweek += 1024;

Works well until the actual GPS week steps from 1523 to 1524 in which 
the wrapped GPS week steps from 499 to 500 and the calculated GPS week 
after unwrapping steps from 1523 to 500. Those receivers frose. A 
firmware update could do this after the wrapping:

if (GPSweek < 500)
	GPSweek += 1024;
GPSweek += 1024;

That would keep them running for another 19 years.

Other receivers have other ways to handle it, including allowing the 
user to give the date as a hint. Infact, the current year is sufficient 
to resolve that wrapping.

Regardless, the GPS time can also "lie", but it is maybe about a decimal 
place less likely than UTC time from a system approach. However, if one 
blindly expects the GPS receiver to always give "correct" time, then one 
has opened up a pandora-box of troubles, as you obviously is not looking 
at the error handling needed particular for GPS receivers. To protect 
yourself you need to understand how they work and what failures and 
mal-functions they can have. But too many times I see them being treated 
as this box that takes a GPS signal and cranks out "correct time". Once 
in place, they are mostly forgotten except on tours among the equipment.

Cheers,
Magnus

From magnus at rubidium.dyndns.org  Sun Oct  4 07:37:42 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 04 Oct 2009 13:37:42 +0200
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <58209.1254654915@critter.freebsd.dk>
References: <58209.1254654915@critter.freebsd.dk>
Message-ID: <4AC88906.30505@rubidium.dyndns.org>

Poul-Henning Kamp wrote:
> In message <4AC87DA2.4040103 at rubidium.dyndns.org>, Magnus Danielson writes:
> 
>> Of course it cannot output a correct UTC solution until it has received 
>> page 18 subframe 4, but it can store the leapsecond offset in 
>> non-volatile RAM since last lock and for most of times that would give 
>> correct UTC from first lock [...]
> 
> And once again, this topic reminds me of my favourite Monty Python
> episode:
> 
> 	"This is an official announcement from the Royal Navy.
> 
> 	Canibalism is a problem the Royal Navy has mostly under control.
> 
> 	[...]
> 	"
> 
> "most of the times" is simply not good enough.
> 

Then you haven't understood the limits. GPS itself only works "most of 
the times". You are focusing on a single issue while a GPS based system 
is exposed to a lot more threats of both systematic and random nature. 
If you can't handle an issue like this, then don't use GPS at all!

It's not all about leapseconds you know.

Besides, one approach to handle lack of page 18, subframe 4 is just not 
to output any time at all. That way you will not give the user the wrong 
impression. Sure, the user would be without the UTC time during the 
wake-up, but you wouldn't "lie". If that is better for you, then use 
that approach.

Also, recall that as GPS reception cannot be guaranteed at all times 
(for all kinds of reasons, including having GPS receiver restarted) you 
better have some form of holdover capability. Now, technically it would 
be lying to you a little for a little while, but if this is within 
system limits then that is fine as it will make the precense of a singal 
more continous. That's how we hide failures to the system. We just wait 
a little before we say we lie about the time.

The important thing here is that various forms of failures is know, 
detected and a suitable remedy can be designed. This is also possible 
for the UTC time from GPS receivers, and the particular little detail of 
having the fresh leapsecond count is one but many of those issues.

Cheers,
Magnus

From phk at phk.freebsd.dk  Sun Oct  4 07:46:35 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 04 Oct 2009 11:46:35 +0000
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: Your message of "Sun, 04 Oct 2009 13:37:42 +0200."
	<4AC88906.30505@rubidium.dyndns.org> 
Message-ID: <75400.1254656795@critter.freebsd.dk>

In message <4AC88906.30505 at rubidium.dyndns.org>, Magnus Danielson writes:
>Poul-Henning Kamp wrote:

>> "most of the times" is simply not good enough.
>> 
>
>Then you haven't understood the limits. GPS itself only works "most of 
>the times". 

The difference is, when GPS does not work, the receiver goes out of
the way to be able to detect and report this.

Using a GPS-UTC delta from memory, before we have an updated value
from the sats is just plain old bogusly wrong.

-- 
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 magnus at rubidium.dyndns.org  Sun Oct  4 08:34:06 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 04 Oct 2009 14:34:06 +0200
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <75400.1254656795@critter.freebsd.dk>
References: <75400.1254656795@critter.freebsd.dk>
Message-ID: <4AC8963E.1050403@rubidium.dyndns.org>

Poul-Henning Kamp wrote:
> In message <4AC88906.30505 at rubidium.dyndns.org>, Magnus Danielson writes:
>> Poul-Henning Kamp wrote:
> 
>>> "most of the times" is simply not good enough.
>>>
>> Then you haven't understood the limits. GPS itself only works "most of 
>> the times". 
> 
> The difference is, when GPS does not work, the receiver goes out of
> the way to be able to detect and report this.

That varies alot, depending on the receivers intended market. Some 
brands has a tradition of doing this.

> Using a GPS-UTC delta from memory, before we have an updated value
> from the sats is just plain old bogusly wrong.

That is what you get when users promote a quick answer over a correct 
answer. Alot of efforts have been spent on delivering quicker answers 
after powerup. You can go the AGPS style and provide it with the 
correction value. That will certainly aid in several senses.

If you required the receiver not to give an answer before it had full 
data, you would get such a receiver.

Another method is simply not to listen to it the first 15 min of 
providing solutions.

Cheers,
Magnus

From clive at davros.org  Sun Oct  4 10:11:16 2009
From: clive at davros.org (Clive D.W. Feather)
Date: Sun, 4 Oct 2009 15:11:16 +0100
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <75400.1254656795@critter.freebsd.dk>
References: <4AC88906.30505@rubidium.dyndns.org>
	<75400.1254656795@critter.freebsd.dk>
Message-ID: <20091004141116.GL90759@davros.org>

Poul-Henning Kamp said:
> Using a GPS-UTC delta from memory, before we have an updated value
> from the sats is just plain old bogusly wrong.

Disagree.

I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
delta until it picks up a new one. For the uses I have for it, an error of
1 or even 5 seconds (but not 30) is far more useful than "no data".

-- 
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 imp at bsdimp.com  Sun Oct  4 12:32:13 2009
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Oct 2009 10:32:13 -0600
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <20091004141116.GL90759@davros.org>
References: <4AC88906.30505@rubidium.dyndns.org>
	<75400.1254656795@critter.freebsd.dk>
	<20091004141116.GL90759@davros.org>
Message-ID: <CE064324-3DFB-4A7D-AF62-05583D16132E@bsdimp.com>

It all depends on your application. If you are controlling Loran C  
signals, no data is better. The Loran stations cant broadcast the  
wrong tomr and have some heuristics that make it a painful operation  
to restart. High power transmitters are like that.   Likewise for a  
stratum 1 ntp server.

Storing a value in ram works poorly for spares that sit on the shelf  
for years at a time.

No error indication is the really bogus part. I could accept an  
educated guess so long as it is flagged as such. Holding it up to  
being correct is bogus.

Mostly works most of the time is not comparable with many gps  
applications. Maybe it is time to learn from them and improve the  
system.


Warner


On Oct 4, 2009, at 8:11 AM, "Clive D.W. Feather" <clive at davros.org>  
wrote:

> Poul-Henning Kamp said:
>> Using a GPS-UTC delta from memory, before we have an updated value
>> from the sats is just plain old bogusly wrong.
>
> Disagree.
>
> I've got a GPS receiver here. It reports UTC so, I presume, uses a  
> stored
> delta until it picks up a new one. For the uses I have for it, an  
> error of
> 1 or even 5 seconds (but not 30) is far more useful than "no data".
>
> -- 
> 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
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>

From phk at phk.freebsd.dk  Sun Oct  4 13:29:11 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 04 Oct 2009 17:29:11 +0000
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: Your message of "Sun, 04 Oct 2009 15:11:16 +0100."
	<20091004141116.GL90759@davros.org> 
Message-ID: <30965.1254677351@critter.freebsd.dk>

In message <20091004141116.GL90759 at davros.org>, "Clive D.W. Feather" writes:
>Poul-Henning Kamp said:
>> Using a GPS-UTC delta from memory, before we have an updated value
>> from the sats is just plain old bogusly wrong.
>
>Disagree.
>
>I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
>delta until it picks up a new one. For the uses I have for it, an error of
>1 or even 5 seconds (but not 30) is far more useful than "no data".

In all likelyhood, it stores the almanac in a cmos-ram chip that also
contains a RTC clock.

And if so, fine, it can do the right thing.

The problem is where you don't have that possibility, for instance if
the GPS is mast-mounted (temperature would kill the batteries, and
replacement would be a PITA), or as Warner has had to deal with:
spare-parts sitting on a shelf for 5 years before they are used (by
that time your Almanac is expired many times over).

-- 
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 lang at unb.ca  Sun Oct  4 14:17:22 2009
From: lang at unb.ca (Richard B. Langley)
Date: Sun,  4 Oct 2009 15:17:22 -0300
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: <4AC885FA.9040706@rubidium.dyndns.org>
References: <21326.1254165579@critter.freebsd.dk><4AC732C8.3060409@rubidium.dyndns.org>
	<20091003.102307.-2117655735.imp@bsdimp.com>
	<AA4DC229FEB6434B988E17561955B4D1@pc52>
	<0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>
	<4AC885FA.9040706@rubidium.dyndns.org>
Message-ID: <1254680242.4ac8e6b236d49@webmail.unb.ca>

Quoting Magnus Danielson <magnus at rubidium.dyndns.org>:

>If the receivers where using L2C they would be able to resolve this from the signal, as
it has a 8192 week >wrapping.

But not quite yet. No IIR-M satellite was transmitting the CNAV messages on L2C until
last week when, as a test, SVN49 started to transmit message type 0. It will be many
years before the full CNAV message is implemented on IIR-M and IIF satellites.

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================



From tvb at LeapSecond.com  Sun Oct  4 19:57:26 2009
From: tvb at LeapSecond.com (Tom Van Baak)
Date: Sun, 4 Oct 2009 16:57:26 -0700
Subject: [LEAPSECS] it's WP7A week in Geneva
References: <4AC88906.30505@rubidium.dyndns.org><75400.1254656795@critter.freebsd.dk>
	<20091004141116.GL90759@davros.org>
Message-ID: <B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>

> I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
> delta until it picks up a new one. For the uses I have for it, an error of
> 1 or even 5 seconds (but not 30) is far more useful than "no data".

Clive,

Or it may be hard-coded; how do you know for sure? OK,
in your case you don't care; but not all cases are that easy.

This is the crux of the problem: you write "I presume". In my
experience, GPS receiver manufacturers don't know or don't
tell how they handle all the edge cases of getting UTC from
GPS time. So users who need ultra-reliable UTC from a GPS
receiver either have to guess, or actually test all the obscure
cases. This is non-trivial, given that real-life tests only happen
once every year or two.

/tvb


From imp at bsdimp.com  Sun Oct  4 21:24:10 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 04 Oct 2009 19:24:10 -0600 (MDT)
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>
References: <75400.1254656795@critter.freebsd.dk>
	<20091004141116.GL90759@davros.org>
	<B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>
Message-ID: <20091004.192410.-879155252.imp@bsdimp.com>

In message: <B1B3DBCA2C4940318EFFE54DC99D4B55 at pc52>
            "Tom Van Baak" <tvb at leapsecond.com> writes:
: > I've got a GPS receiver here. It reports UTC so, I presume, uses a stored
: > delta until it picks up a new one. For the uses I have for it, an error of
: > 1 or even 5 seconds (but not 30) is far more useful than "no data".
: 
: Clive,
: 
: Or it may be hard-coded; how do you know for sure? OK,
: in your case you don't care; but not all cases are that easy.
: 
: This is the crux of the problem: you write "I presume". In my
: experience, GPS receiver manufacturers don't know or don't
: tell how they handle all the edge cases of getting UTC from
: GPS time. So users who need ultra-reliable UTC from a GPS
: receiver either have to guess, or actually test all the obscure
: cases. This is non-trivial, given that real-life tests only happen
: once every year or two.

I'm sure that the folks who have it working have good access to
simulators.  I'm also fairly sure that more than half of the gear out
there will fall over dead for a negative leap second...

Warner


From clive at davros.org  Mon Oct  5 12:10:12 2009
From: clive at davros.org (Clive D.W. Feather)
Date: Mon, 5 Oct 2009 17:10:12 +0100
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>
References: <20091004141116.GL90759@davros.org>
	<B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>
Message-ID: <20091005161012.GE88765@davros.org>

> Or it may be hard-coded; how do you know for sure? OK,
> in your case you don't care; but not all cases are that easy.
[...]

I agree.

However, it negates the statement that a guess is always worse than "no
data".

-- 
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 sla at ucolick.org  Mon Oct  5 13:21:48 2009
From: sla at ucolick.org (Steve Allen)
Date: Mon, 5 Oct 2009 10:21:48 -0700
Subject: [LEAPSECS] CGSIC 49 Sam Stein/Symmetricom as PDF
Message-ID: <20091005172148.GT22483@ucolick.org>

For ease of viewing, I have the Stein/Symmetricom presentation
as converted by OpenOffice to PDF

http://www.ucolick.org/~sla/leapsecs/42Leap_Seconds_final.pdf

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    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  Mon Oct  5 13:10:31 2009
From: sla at ucolick.org (Steve Allen)
Date: Mon, 5 Oct 2009 10:10:31 -0700
Subject: [LEAPSECS] CGSIC is posted
Message-ID: <20091005171031.GR22483@ucolick.org>

Their webserver seems a bit overtaxed, but the contributions are here

http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/49th_CGSIC_Meeting_Agenda.htm

This includes the Barbie-esque "Leap seconds are hard" talk, which
in some sense addresses the "all GPS receivers are different" topic
in recent discussion here.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From seaman at noao.edu  Mon Oct  5 16:02:53 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Oct 2009 13:02:53 -0700
Subject: [LEAPSECS] Hazarding a guess
In-Reply-To: <20091005161012.GE88765@davros.org>
References: <20091004141116.GL90759@davros.org>
	<B1B3DBCA2C4940318EFFE54DC99D4B55@pc52>
	<20091005161012.GE88765@davros.org>
Message-ID: <531F73F2-1B15-42CA-A134-7CAB36B7AD12@noao.edu>

I have been enjoying the spirited discussion.  Many on the astronomy  
side are attending Astronomical Data Analysis Software & Systems XIX  
this week in Sapporo.  Today's sessions in particular focus on the  
time domain:

	http://www.adass2009.jp/program/#oct6

For myself, the sixteen intervening timezones certainly bring home the  
importance of time :-)

Clive D.W. Feather wrote:

> However, it negates the statement that a guess is always worse than  
> "no data".

I would be more accurate to call it an approximation.  Not more  
accurate because the word is more highfalutin', but because it  
emphasizes that a rigorous (if sometimes simple) process should be  
followed to reach this guess.

Time is all about estimation.  The heart of the issue is who makes the  
guesses, where in the system they are made, and what constrains them.

Rob


From mcalabre at atnf.csiro.au  Mon Oct  5 20:42:19 2009
From: mcalabre at atnf.csiro.au (Mark Calabretta)
Date: Tue, 06 Oct 2009 11:42:19 +1100
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: Your message of Sun 2009/10/04 12:49:06 +0200
	<4AC87DA2.4040103@rubidium.dyndns.org> 
Message-ID: <E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>


On Sun 2009/10/04 12:49:06 +0200, Magnus Danielson wrote

>Of course it cannot output a correct UTC solution until it has received 
>page 18 subframe 4, but it can store the leapsecond offset in 
>non-volatile RAM since last lock and for most of times that would give 
>correct UTC from first lock. How many if any receiver uses that, I do 
>not know, but it is technically possible, just as you store the almenac 
>data and last known position in order to accelerate those first 12,5 
>min. Recall, for this strategy to fail, the receiver must have been 
>turned off over a leap-second event. Most times it is turned off is not 
>a leap-second event.

Given that leap seconds are announced six months in advance, how
difficult would it be for GPS to disseminate that information
and for receivers to store and use it?

Mark Calabretta



From imp at bsdimp.com  Mon Oct  5 21:06:54 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Oct 2009 19:06:54 -0600 (MDT)
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
References: <4AC87DA2.4040103@rubidium.dyndns.org>
	<E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
Message-ID: <20091005.190654.2139179808.imp@bsdimp.com>

In message: <E1Muy8B-0003lK-DW at grus.atnf.CSIRO.AU>
            Mark Calabretta <mcalabre at atnf.csiro.au> writes:
: 
: On Sun 2009/10/04 12:49:06 +0200, Magnus Danielson wrote
: 
: >Of course it cannot output a correct UTC solution until it has received 
: >page 18 subframe 4, but it can store the leapsecond offset in 
: >non-volatile RAM since last lock and for most of times that would give 
: >correct UTC from first lock. How many if any receiver uses that, I do 
: >not know, but it is technically possible, just as you store the almenac 
: >data and last known position in order to accelerate those first 12,5 
: >min. Recall, for this strategy to fail, the receiver must have been 
: >turned off over a leap-second event. Most times it is turned off is not 
: >a leap-second event.
: 
: Given that leap seconds are announced six months in advance, how
: difficult would it be for GPS to disseminate that information
: and for receivers to store and use it?

They already do that.

However, it turns out there are a number of edge-case ambiguities that
make for interesting problems that have been talked about here...

The fundamental problem is that leap seconds are announced 6 months in
advance.  This is too little time.

Warner

From ashley at semantic.org  Mon Oct  5 21:12:24 2009
From: ashley at semantic.org (Ashley Yakeley)
Date: Mon, 05 Oct 2009 18:12:24 -0700
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <20091005.190654.2139179808.imp@bsdimp.com>
References: <4AC87DA2.4040103@rubidium.dyndns.org>
	<E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
	<20091005.190654.2139179808.imp@bsdimp.com>
Message-ID: <1254791544.3766.20.camel@sherbourne>

On Mon, 2009-10-05 at 19:06 -0600, M. Warner Losh wrote:
> The fundamental problem is that leap seconds are announced 6 months in
> advance.  This is too little time.

Predictability might be extended by careful manipulation of a system of
dams on rivers near the equator.

-- 
Ashley Yakeley


From imp at bsdimp.com  Mon Oct  5 21:43:50 2009
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 5 Oct 2009 19:43:50 -0600
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <1254791544.3766.20.camel@sherbourne>
References: <4AC87DA2.4040103@rubidium.dyndns.org>
	<E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
	<20091005.190654.2139179808.imp@bsdimp.com>
	<1254791544.3766.20.camel@sherbourne>
Message-ID: <347E5E0A-AB36-4837-8A37-34D6C5F754AB@bsdimp.com>

Things are already predictable out 18-24 months. And we know the long  
term trends. Leap seconds could be annonced out 2 years at least with  
no other changes to the current system.  There is nothing magic about  
6 months.

Warner


On Oct 5, 2009, at 7:12 PM, Ashley Yakeley <ashley at semantic.org> wrote:

> On Mon, 2009-10-05 at 19:06 -0600, M. Warner Losh wrote:
>> The fundamental problem is that leap seconds are announced 6 months  
>> in
>> advance.  This is too little time.
>
> Predictability might be extended by careful manipulation of a system  
> of
> dams on rivers near the equator.
>
> -- 
> Ashley Yakeley
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs
>
>

From ashtongj at comcast.net  Mon Oct  5 21:56:48 2009
From: ashtongj at comcast.net (Gerard Ashton)
Date: Mon, 5 Oct 2009 21:56:48 -0400
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
Message-ID: <1EBBF6BD136D4B7AA983517FC850ED93@grendel>

I find it remarkable that one group of time users chose a
particular time dissemination mode (GPS) and made the typical
array of poor decisions / errors with software. They also
create a rather arbitrary demand of obtaining correct UTC
within 5 minutes of installing hardware that has been
sitting on a shelf for years.

They then decide the solution to there largely self-made
problems is that the rest of the world should:
 -Redefine the name for the most widely used time scale in a way that conflicts
  with the present definition.
 -Everyone who wrote correct software to re-correct the software.
 -Abandon any cultural connection between civil time and actual earth rotation
 -Rewrite laws that refer to mean time so they refer to UTC, since the
  difference between mean time and UTC will gradually become legally
significant.

I'm inclined to reject the proposal on the grounds that the proposers are
too arrogant.

Gerry Ashton
 


From imp at bsdimp.com  Mon Oct  5 22:33:51 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 Oct 2009 20:33:51 -0600 (MDT)
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <1EBBF6BD136D4B7AA983517FC850ED93@grendel>
References: <E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
	<1EBBF6BD136D4B7AA983517FC850ED93@grendel>
Message-ID: <20091005.203351.1649820314.imp@bsdimp.com>

In message: <1EBBF6BD136D4B7AA983517FC850ED93 at grendel>
            "Gerard Ashton" <ashtongj at comcast.net> writes:
: I find it remarkable that one group of time users chose a
: particular time dissemination mode (GPS) and made the typical
: array of poor decisions / errors with software. They also
: create a rather arbitrary demand of obtaining correct UTC
: within 5 minutes of installing hardware that has been
: sitting on a shelf for years.

Keep in mind that the people that wanted the solution, and the people
that implemented them were two different sets of people.

: They then decide the solution to there largely self-made
: problems is that the rest of the world should:
:  -Redefine the name for the most widely used time scale in a way that conflicts
:   with the present definition.

The problem exists independent of GPS.  GPS is just the best way to
demonstrate the problem.  The basic problem is that UTC is an
irregular system (sorry, has a variable radix, which is the same thing
from a software point of view).  Experience has shown that the
disconnect causes problems.


:  -Everyone who wrote correct software to re-correct the software.

Actually it depends on what you define as correct.  Everybody that
implements leap seconds in time keeping will automatically be correct
if they were eliminated.  It would still work if leap seconds were
scheduled out more than 6 months in advance too.

People that wrote code assuming DUT1 < 1s could be argued to not be
correct.  They are merely close to correct.  It bounds the error.  A
more correct program would accept better corrections.  Many telescopes
already download better estimates from the web and would be unaffected
either by their elimination or their scheduling (although their
elimination would eventually overflow fixed width formats in some
sources of DUT1).

:  -Abandon any cultural connection between civil time and actual
: earth rotation

The railroads already did that 150 years ago when standard time was
adopted.  Most people live their lives where the sun has an apparent
error of tens or hundreds of minutes off.  This poses no problem to
people at all.  This suggests that UTC's DUT1 requirement likely could
be relaxed without any major cultual damage.

We're also putting off the problem.  Given the quadratic acceleration
of drift, one day we'll have to have a better system is
synchronization to the earth's rotation is to remain viable.

:  -Rewrite laws that refer to mean time so they refer to UTC, since the
:   difference between mean time and UTC will gradually become legally
: significant.

Actually, the laws that refer to UTC are fine.  If the UTC definition
is tweaked, they are still valid.  It is the ones that refer to mean
solar time that are problematical.

: I'm inclined to reject the proposal on the grounds that the proposers are
: too arrogant.

Since your arguments are overstated, maybe your conclusion is too.

Keep in mind that there are many proposals that have been circulated
and the tone of your post is highly arrogant in that it ignores the
others and is mostly an emotional reaction.  The earth has shown
itself to be an unreliable time keeper, and the current system is
showing signs of strain...

Warner

: Gerry Ashton
:  
: 
: _______________________________________________
: LEAPSECS mailing list
: LEAPSECS at leapsecond.com
: http://six.pairlist.net/mailman/listinfo/leapsecs
: 
: 

From seaman at noao.edu  Tue Oct  6 02:36:00 2009
From: seaman at noao.edu (Rob Seaman)
Date: Mon, 5 Oct 2009 23:36:00 -0700
Subject: [LEAPSECS] it's WP7A week in Geneva
In-Reply-To: <20091005.203351.1649820314.imp@bsdimp.com>
References: <E1Muy8B-0003lK-DW@grus.atnf.CSIRO.AU>
	<1EBBF6BD136D4B7AA983517FC850ED93@grendel>
	<20091005.203351.1649820314.imp@bsdimp.com>
Message-ID: <22F6E167-54C8-42A1-BA6F-911A4A65921C@noao.edu>

Sitting in a plenary session - will keep this short.

Executive summary:  GPS is great stuff.  Universal Time is also great  
stuff.  They are not the same great stuff.

M. Warner Losh wrote:

> Everybody that implements leap seconds in time keeping will  
> automatically be correct if they were eliminated.

This has not been demonstrated to be correct.  Some systems care about  
mean solar time.  You are asserting that A) astronomers don't matter,  
and B) no other systems in the world care about Earth orientation to a  
degree we need be concerned about.

> It would still work if leap seconds were scheduled out more than 6  
> months in advance too.

No argument there!  By all means increase the announcement horizon.

> Most people live their lives where the sun has an apparent error of  
> tens or hundreds of minutes off.

I'll make my usual observation that this confuses periodic and secular  
effects.  See list archive.

> We're also putting off the problem.  Given the quadratic  
> acceleration of drift, one day we'll have to have a better system is  
> synchronization to the earth's rotation is to remain viable.

The quadratic behavior applies no matter what.  Embargoing leap  
seconds does not make them go away.  Unless we believe night can turn  
into day, civil time must be synched to the Earth's rotation to match  
some constraints.  By all means let's debate the constraints.  It is  
not viable, however, to simply ignore the sun in the sky.  As the  
Earth clock slows (albeit thousands of years from now), it will become  
obvious that we can't pretend atomic time and solar time are the same  
thing.  Why not admit this fact of life now?

The way to reach a robust consensus on what constitutes a "better  
system" is to discover and debate the underlying requirements of the  
system.  Define the problem appropriately and the range of acceptable  
solutions will take care of itself.

Rob


From nimh at pipe.nl  Tue Oct  6 07:25:56 2009
From: nimh at pipe.nl (Nero Imhard)
Date: Tue, 6 Oct 2009 13:25:56 +0200 (CEST)
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: <0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>
References: <21326.1254165579@critter.freebsd.dk><4AC732C8.3060409@rubidium.dyndns.org>
	<20091003.102307.-2117655735.imp@bsdimp.com>
	<AA4DC229FEB6434B988E17561955B4D1@pc52>
	<0B8B21EB-DBEA-4DEC-89C5-F27557F37495@noao.edu>
Message-ID: <e8fcfabf1874eff9e7b857bf0282e50e.squirrel@mx.pipe.nl>

On 2009-10-03, at 23:56, Rob Seaman wrote:

> However, is it a true assertion that currently deployed GPS receivers
> return GPS time significantly more reliably (all those 9's) than they
> do UTC?  (Assuming a particular model supports both?)
>
> It's hard to see this as supporting a position that "Only UTC can be
> disseminated"...

It was not even clear how that phrase was meant, let alone how one would
arrive at such a conclusion.

Some possible interpretations:
- Only the time scale currently called "UTC" can be disseminated. (why??)
- It is not possible to disseminate a clean count of SI seconds (why not??)
- It is only practical to disseminate a time scale that has a simple
    relationship to legal time (i.e. UTC).
- whatever the disseminated time scale, it has to be called "UTC" (sounds
    like ITU's position)

etc.

Does anyone have a clue?

N

From phk at phk.freebsd.dk  Tue Oct  6 07:38:36 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 06 Oct 2009 11:38:36 +0000
Subject: [LEAPSECS] Reliability (was Re: it's WP7A week in Geneva)
In-Reply-To: Your message of "Tue, 06 Oct 2009 13:25:56 +0200."
	<e8fcfabf1874eff9e7b857bf0282e50e.squirrel@mx.pipe.nl> 
Message-ID: <66312.1254829116@critter.freebsd.dk>

In message <e8fcfabf1874eff9e7b857bf0282e50e.squirrel at mx.pipe.nl>, "Nero Imhard
" writes:
>On 2009-10-03, at 23:56, Rob Seaman wrote:

>> It's hard to see this as supporting a position that "Only UTC can be
>> disseminated"...
>
>Does anyone have a clue?

I read it as:

	"I won't get invited to the BIPM metrological barbeque if
	I advocate disseminating TAI, because those guys really
	don't want that."

:-)

Poul-Henning

-- 
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 sla at ucolick.org  Thu Oct  8 03:46:53 2009
From: sla at ucolick.org (Steve Allen)
Date: Thu, 8 Oct 2009 00:46:53 -0700
Subject: [LEAPSECS] yet another satellite time scale
Message-ID: <20091008074653.GA19929@ucolick.org>

Within the recent CGSIC proceedings is the overview presentation by
Lewandowski of the BIPM.
http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/Reports/%5B39%5DTiming_WL_General.pdf
It includes one page plotting the various satellite time scales and
another showing the Tower of Babel.

With gratitude toward that presentation and the Peoples Republic of
China I have enhanced my web pages to include Compass or BeiDou System
Time (BST) as one of what are now three discernibly distinct broadcast
time scales for navigation which run parallel to the original
Ephemeris/Terrestrial Time.
http://www.ucolick.org/~sla/leapsecs/deltat.html
This plot is, of course, not making it clear that GPS time and Galileo
System time (and perhaps others yet to come) are (at nanosecond
precision) not actually the same time scale.

In the light of all this I find myself ever more confused by the
assertion that "only UTC can be disseminated".  Plainly there are lots
of time scales being broadcast, and according to the BIPM Circular T
some of the ones named UTC(k) are less stable than ones not named UTC.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From matsakis.demetrios at usno.navy.mil  Fri Oct  9 11:02:45 2009
From: matsakis.demetrios at usno.navy.mil (Matsakis, Demetrios)
Date: Fri, 9 Oct 2009 11:02:45 -0400
Subject: [LEAPSECS] Windows Time's "Great Leap Forward"
Message-ID: <91772DEC8A29C048A9BFBE32C49CEB724DB6D7@echo.usno.navy.mil>

Microsoft's NTP package gives no notice of a pending leap second, even
when acting as a server.  Here are some pastes from Microsoft's web
site:

"The Windows Time service does not indicate the value of the Leap
Indicator when the Windows Time service receives a packet that includes
a leap second. (The Leap Indicator indicates whether an impending leap
second is to be inserted or deleted in the last minute of the current
day.) Therefore, after the leap second occurs, the NTP client that is
running Windows Time service is one second faster than the actual time.
This difference is resolved at the next time synchronization."

"When the Windows Time service is working as an NTP server 

No method exists to include a leap second for the Windows Time service."


See http://support.microsoft.com/kb/909614

From zefram at fysh.org  Fri Oct  9 11:32:41 2009
From: zefram at fysh.org (Zefram)
Date: Fri, 9 Oct 2009 16:32:41 +0100
Subject: [LEAPSECS] Windows Time's "Great Leap Forward"
In-Reply-To: <91772DEC8A29C048A9BFBE32C49CEB724DB6D7@echo.usno.navy.mil>
References: <91772DEC8A29C048A9BFBE32C49CEB724DB6D7@echo.usno.navy.mil>
Message-ID: <20091009153241.GI20296@fysh.org>

Matsakis, Demetrios wrote:
>Microsoft's NTP package gives no notice of a pending leap second, even
>when acting as a server.

No great surprise.  Microsoft really doesn't get NTP.  Although recent
versions of Windows have come with an NTP client, as far as I can tell
this client is incapable of performing anything resembling the NTP
clock synchronisation algorithm.  It merely steps the local clock to
match the NTP server, each time it receives a reply from the server,
and never steers the clock speed.  It's typically configured to ask a
server for the time once a *week*.

This is not clock synchronisation as we know it, and one shouldn't be
misled by the fact that it's capable of using a proper NTP server as
its time source.

-zefram

From phk at phk.freebsd.dk  Fri Oct  9 11:51:08 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 09 Oct 2009 15:51:08 +0000
Subject: [LEAPSECS] Windows Time's "Great Leap Forward"
In-Reply-To: Your message of "Fri, 09 Oct 2009 16:32:41 +0100."
	<20091009153241.GI20296@fysh.org> 
Message-ID: <12710.1255103468@critter.freebsd.dk>

In message <20091009153241.GI20296 at fysh.org>, Zefram writes:
>Matsakis, Demetrios wrote:
>>Microsoft's NTP package gives no notice of a pending leap second, even
>>when acting as a server.
>
>No great surprise.  Microsoft really doesn't get NTP.

s/NTP/time at all/



-- 
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 magnus at rubidium.dyndns.org  Fri Oct  9 14:24:34 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Fri, 09 Oct 2009 20:24:34 +0200
Subject: [LEAPSECS] yet another satellite time scale
In-Reply-To: <20091008074653.GA19929@ucolick.org>
References: <20091008074653.GA19929@ucolick.org>
Message-ID: <4ACF7FE2.4050809@rubidium.dyndns.org>

Steve,

Steve Allen wrote:
> Within the recent CGSIC proceedings is the overview presentation by
> Lewandowski of the BIPM.
> http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/Reports/%5B39%5DTiming_WL_General.pdf
> It includes one page plotting the various satellite time scales and
> another showing the Tower of Babel.
> 
> With gratitude toward that presentation and the Peoples Republic of
> China I have enhanced my web pages to include Compass or BeiDou System
> Time (BST) as one of what are now three discernibly distinct broadcast
> time scales for navigation which run parallel to the original
> Ephemeris/Terrestrial Time.
> http://www.ucolick.org/~sla/leapsecs/deltat.html
> This plot is, of course, not making it clear that GPS time and Galileo
> System time (and perhaps others yet to come) are (at nanosecond
> precision) not actually the same time scale.

There are more...

GLONASS timescale is a three-hour offset from UTC(SU), see GLONASS ICD.

WAAS, EGNOS and MSAS have their own timescales, maintained to be 
roughtly that of GPS.

Cheers,
Magnus

From jnatale at juniper.net  Fri Oct  9 16:38:35 2009
From: jnatale at juniper.net (Jonathan Natale)
Date: Fri, 9 Oct 2009 16:38:35 -0400
Subject: [LEAPSECS] LEAPSECS Digest, Vol 34, Issue 8
In-Reply-To: <mailman.25.1255104033.53308.leapsecs@leapsecond.com>
References: <mailman.25.1255104033.53308.leapsecs@leapsecond.com>
Message-ID: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>

AFAIK, routers also just re-sych.  The OS's are not capable of xx:xx:60 time.  For reading router logs this is fine in most cases which is all NTP is really for.  I don't think they simply step the time, I am pretty sure they do tweak the freq.  I could be wrong and I am NOT representing Juniper here, just my thoughts. :-)


-----Original Message-----
From: leapsecs-bounces at leapsecond.com [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of leapsecs-request at leapsecond.com
Sent: Friday, October 09, 2009 12:01 PM
To: leapsecs at leapsecond.com
Subject: LEAPSECS Digest, Vol 34, Issue 8

Send LEAPSECS mailing list submissions to
	leapsecs at leapsecond.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://six.pairlist.net/mailman/listinfo/leapsecs
or, via email, send a message with subject or body 'help' to
	leapsecs-request at leapsecond.com

You can reach the person managing the list at
	leapsecs-owner at leapsecond.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of LEAPSECS digest..."


Today's Topics:

   1. Windows Time's "Great Leap Forward" (Matsakis, Demetrios)
   2. Re: Windows Time's "Great Leap Forward" (Zefram)
   3. Re: Windows Time's "Great Leap Forward" (Poul-Henning Kamp)


----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Oct 2009 11:02:45 -0400
From: "Matsakis, Demetrios" <matsakis.demetrios at usno.navy.mil>
Subject: [LEAPSECS] Windows Time's "Great Leap Forward"
To: "Leap Second Discussion List" <leapsecs at leapsecond.com>
Message-ID:
	<91772DEC8A29C048A9BFBE32C49CEB724DB6D7 at echo.usno.navy.mil>
Content-Type: text/plain;	charset="us-ascii"

Microsoft's NTP package gives no notice of a pending leap second, even
when acting as a server.  Here are some pastes from Microsoft's web
site:

"The Windows Time service does not indicate the value of the Leap
Indicator when the Windows Time service receives a packet that includes
a leap second. (The Leap Indicator indicates whether an impending leap
second is to be inserted or deleted in the last minute of the current
day.) Therefore, after the leap second occurs, the NTP client that is
running Windows Time service is one second faster than the actual time.
This difference is resolved at the next time synchronization."

"When the Windows Time service is working as an NTP server 

No method exists to include a leap second for the Windows Time service."


See http://support.microsoft.com/kb/909614


------------------------------

Message: 2
Date: Fri, 9 Oct 2009 16:32:41 +0100
From: Zefram <zefram at fysh.org>
Subject: Re: [LEAPSECS] Windows Time's "Great Leap Forward"
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Message-ID: <20091009153241.GI20296 at fysh.org>
Content-Type: text/plain; charset=us-ascii

Matsakis, Demetrios wrote:
>Microsoft's NTP package gives no notice of a pending leap second, even
>when acting as a server.

No great surprise.  Microsoft really doesn't get NTP.  Although recent
versions of Windows have come with an NTP client, as far as I can tell
this client is incapable of performing anything resembling the NTP
clock synchronisation algorithm.  It merely steps the local clock to
match the NTP server, each time it receives a reply from the server,
and never steers the clock speed.  It's typically configured to ask a
server for the time once a *week*.

This is not clock synchronisation as we know it, and one shouldn't be
misled by the fact that it's capable of using a proper NTP server as
its time source.

-zefram


------------------------------

Message: 3
Date: Fri, 09 Oct 2009 15:51:08 +0000
From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
Subject: Re: [LEAPSECS] Windows Time's "Great Leap Forward"
To: Leap Second Discussion List <leapsecs at leapsecond.com>
Message-ID: <12710.1255103468 at critter.freebsd.dk>

In message <20091009153241.GI20296 at fysh.org>, Zefram writes:
>Matsakis, Demetrios wrote:
>>Microsoft's NTP package gives no notice of a pending leap second, even
>>when acting as a server.
>
>No great surprise.  Microsoft really doesn't get NTP.

s/NTP/time at all/



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


------------------------------

_______________________________________________
LEAPSECS mailing list
LEAPSECS at leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs


End of LEAPSECS Digest, Vol 34, Issue 8
***************************************

From imp at bsdimp.com  Fri Oct  9 19:13:43 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri, 09 Oct 2009 17:13:43 -0600 (MDT)
Subject: [LEAPSECS] LEAPSECS Digest, Vol 34, Issue 8
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
References: <mailman.25.1255104033.53308.leapsecs@leapsecond.com>
	<13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
Message-ID: <20091009.171343.-92838350.imp@bsdimp.com>

In message: <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
            Jonathan Natale <jnatale at juniper.net> writes:
: AFAIK, routers also just re-sych.  The OS's are not capable of
: xx:xx:60 time.  For reading router logs this is fine in most cases
: which is all NTP is really for.  I don't think they simply step the
: time, I am pretty sure they do tweak the freq.  I could be wrong and
: I am NOT representing Juniper here, just my thoughts. :-)

FreeBSD will cope with the xx:xx:60 second correctly, assuming it is
told about the leapsecond soon enough.  Not all other parts of the
system can cope with the xx:xx:60, but that's a posix time_t
limitation that you can't do anything about[*].

Warner

[*] The 'right' timezone files attempt to do things correctly, but in
doing so they break time_t definition...

From magnus at rubidium.dyndns.org  Fri Oct  9 22:54:17 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 10 Oct 2009 04:54:17 +0200
Subject: [LEAPSECS] LEAPSECS Digest, Vol 34, Issue 8
In-Reply-To: <20091009.171343.-92838350.imp@bsdimp.com>
References: <mailman.25.1255104033.53308.leapsecs@leapsecond.com>	<13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
Message-ID: <4ACFF759.3090903@rubidium.dyndns.org>

M. Warner Losh wrote:
> In message: <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
>             Jonathan Natale <jnatale at juniper.net> writes:
> : AFAIK, routers also just re-sych.  The OS's are not capable of
> : xx:xx:60 time.  For reading router logs this is fine in most cases
> : which is all NTP is really for.  I don't think they simply step the
> : time, I am pretty sure they do tweak the freq.  I could be wrong and
> : I am NOT representing Juniper here, just my thoughts. :-)
> 
> FreeBSD will cope with the xx:xx:60 second correctly, assuming it is
> told about the leapsecond soon enough.  Not all other parts of the
> system can cope with the xx:xx:60, but that's a posix time_t
> limitation that you can't do anything about[*].
> 
> Warner
> 
> [*] The 'right' timezone files attempt to do things correctly, but in
> doing so they break time_t definition...

I assumed you meant to say that it breaks the POSIX time_t definition.

Cheers,
Magnus

From imp at bsdimp.com  Fri Oct  9 23:14:52 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri, 09 Oct 2009 21:14:52 -0600 (MDT)
Subject: [LEAPSECS] LEAPSECS Digest, Vol 34, Issue 8
In-Reply-To: <4ACFF759.3090903@rubidium.dyndns.org>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
Message-ID: <20091009.211452.961222257.imp@bsdimp.com>

In message: <4ACFF759.3090903 at rubidium.dyndns.org>
            Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: M. Warner Losh wrote:
: > In message: <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
: >             Jonathan Natale <jnatale at juniper.net> writes:
: > : AFAIK, routers also just re-sych.  The OS's are not capable of
: > : xx:xx:60 time.  For reading router logs this is fine in most cases
: > : which is all NTP is really for.  I don't think they simply step the
: > : time, I am pretty sure they do tweak the freq.  I could be wrong and
: > : I am NOT representing Juniper here, just my thoughts. :-)
: > 
: > FreeBSD will cope with the xx:xx:60 second correctly, assuming it is
: > told about the leapsecond soon enough.  Not all other parts of the
: > system can cope with the xx:xx:60, but that's a posix time_t
: > limitation that you can't do anything about[*].
: > 
: > Warner
: > 
: > [*] The 'right' timezone files attempt to do things correctly, but in
: > doing so they break time_t definition...
: 
: I assumed you meant to say that it breaks the POSIX time_t definition.

Yes.  The most current time_t definition is the one codified by POSIX.
Older standards are fuzzier about what time_t really means.

Warner


From magnus at rubidium.dyndns.org  Sat Oct 10 09:28:50 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 10 Oct 2009 15:28:50 +0200
Subject: [LEAPSECS] LEAPSECS Digest, Vol 34, Issue 8
In-Reply-To: <20091009.211452.961222257.imp@bsdimp.com>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>	<20091009.171343.-92838350.imp@bsdimp.com>	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
Message-ID: <4AD08C12.4090100@rubidium.dyndns.org>

M. Warner Losh wrote:
> In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
> : M. Warner Losh wrote:
> : > In message: <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
> : >             Jonathan Natale <jnatale at juniper.net> writes:
> : > : AFAIK, routers also just re-sych.  The OS's are not capable of
> : > : xx:xx:60 time.  For reading router logs this is fine in most cases
> : > : which is all NTP is really for.  I don't think they simply step the
> : > : time, I am pretty sure they do tweak the freq.  I could be wrong and
> : > : I am NOT representing Juniper here, just my thoughts. :-)
> : > 
> : > FreeBSD will cope with the xx:xx:60 second correctly, assuming it is
> : > told about the leapsecond soon enough.  Not all other parts of the
> : > system can cope with the xx:xx:60, but that's a posix time_t
> : > limitation that you can't do anything about[*].
> : > 
> : > Warner
> : > 
> : > [*] The 'right' timezone files attempt to do things correctly, but in
> : > doing so they break time_t definition...
> : 
> : I assumed you meant to say that it breaks the POSIX time_t definition.
> 
> Yes.  The most current time_t definition is the one codified by POSIX.
> Older standards are fuzzier about what time_t really means.

Indeed. As there exist several time_t definitions, I wanted to make sure 
you was refering to the POSIX mapping of UTC time into time_t, which 
forms an "interesting" timescale of its own, almost but not close 
enought to UTC.

Cheers,
Magnus

From joegwinn at comcast.net  Sat Oct 10 10:36:16 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sat, 10 Oct 2009 10:36:16 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <4AD08C12.4090100@rubidium.dyndns.org>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
	<4AD08C12.4090100@rubidium.dyndns.org>
Message-ID: <p06240800c6f64b0a89ae@[192.168.1.212]>

At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
>M. Warner Losh wrote:
>>In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
>>: M. Warner Losh wrote:
>>: > In message: 
>><13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
>>: >             Jonathan Natale <jnatale at juniper.net> writes:
>>: > : AFAIK, routers also just re-sych.  The OS's are not capable of
>>: > : xx:xx:60 time.  For reading router logs this is fine in most cases
>>: > : which is all NTP is really for.  I don't think they simply step the
>>: > : time, I am pretty sure they do tweak the freq.  I could be wrong and
>>: > : I am NOT representing Juniper here, just my thoughts. :-)
>>: > : > FreeBSD will cope with the xx:xx:60 second correctly, assuming it is
>>: > told about the leapsecond soon enough.  Not all other parts of the
>>: > system can cope with the xx:xx:60, but that's a posix time_t
>>: > limitation that you can't do anything about[*].
>>: > : > Warner
>>: > : > [*] The 'right' timezone files attempt to do things correctly, but in
>>: > doing so they break time_t definition...
>>: : I assumed you meant to say that it breaks the POSIX time_t definition.
>>
>>Yes.  The most current time_t definition is the one codified by POSIX.
>>Older standards are fuzzier about what time_t really means.
>
>Indeed. As there exist several time_t definitions, I wanted to make 
>sure you was refering to the POSIX mapping of UTC time into time_t, 
>which forms an "interesting" timescale of its own, almost but not 
>close enough to UTC.

By definition, POSIX Time is closer to TAI than to UTC, but in 
practice time in POSIX-compliant computers is usually NTP steered to 
approximate UTC (most common) or to GPS System Time (where 
leapseconds cannot be tolerated).

Joe Gwinn

From magnus at rubidium.dyndns.org  Sat Oct 10 11:10:17 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 10 Oct 2009 17:10:17 +0200
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <p06240800c6f64b0a89ae@[192.168.1.212]>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>	<20091009.171343.-92838350.imp@bsdimp.com>	<4ACFF759.3090903@rubidium.dyndns.org>	<20091009.211452.961222257.imp@bsdimp.com>	<4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
Message-ID: <4AD0A3D9.2080403@rubidium.dyndns.org>

Joe,

Joe Gwinn wrote:
> At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
>> M. Warner Losh wrote:
>>> In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
>>> : M. Warner Losh wrote:
>>> : > In message: 
>>> <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
>>> : >             Jonathan Natale <jnatale at juniper.net> writes:
>>> : > : AFAIK, routers also just re-sych.  The OS's are not capable of
>>> : > : xx:xx:60 time.  For reading router logs this is fine in most cases
>>> : > : which is all NTP is really for.  I don't think they simply step 
>>> the
>>> : > : time, I am pretty sure they do tweak the freq.  I could be 
>>> wrong and
>>> : > : I am NOT representing Juniper here, just my thoughts. :-)
>>> : > : > FreeBSD will cope with the xx:xx:60 second correctly, 
>>> assuming it is
>>> : > told about the leapsecond soon enough.  Not all other parts of the
>>> : > system can cope with the xx:xx:60, but that's a posix time_t
>>> : > limitation that you can't do anything about[*].
>>> : > : > Warner
>>> : > : > [*] The 'right' timezone files attempt to do things 
>>> correctly, but in
>>> : > doing so they break time_t definition...
>>> : : I assumed you meant to say that it breaks the POSIX time_t 
>>> definition.
>>>
>>> Yes.  The most current time_t definition is the one codified by POSIX.
>>> Older standards are fuzzier about what time_t really means.
>>
>> Indeed. As there exist several time_t definitions, I wanted to make 
>> sure you was refering to the POSIX mapping of UTC time into time_t, 
>> which forms an "interesting" timescale of its own, almost but not 
>> close enough to UTC.
> 
> By definition, POSIX Time is closer to TAI than to UTC, but in practice 
> time in POSIX-compliant computers is usually NTP steered to approximate 
> UTC (most common) or to GPS System Time (where leapseconds cannot be 
> tolerated).

As the text of subclause 4.14 of the POSIX base standard defines it, it 
is based on "Coordinated Universal Time" and the "name" is mapped into 
seconds as defined by the mapping function. This makes it follow UTC 
while maintaining the mental feel of being TAI-based without any leap 
seconds, but it is closer to UTC as only occasionally (on the leap 
second second) differs by a second during a second while it has a so far 
constantly increasing difference to TAI. So on average it is much closer 
to UTC than TAI.

So I respectfully disagree with your statement that POSIX Time is closer 
to TAI than UTC. I think that it is closer to UTC and that the NTP 
steering honour the POSIX UTC to time_t mapping.

A user wishing to display correct UTC time during leap-second would need 
to querry the NTP  kernel over the provided interface to recover the 
extra information, which is possible when the NTP has the necessary 
leapsecond information and is enabled.

I had the distinct memory that we discussed this indepth some time ago 
both on and off list(s).

Cheers,
Magnus

From phk at phk.freebsd.dk  Sat Oct 10 12:20:42 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 10 Oct 2009 16:20:42 +0000
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: Your message of "Sat, 10 Oct 2009 10:36:16 -0400."
	<p06240800c6f64b0a89ae@[192.168.1.212]> 
Message-ID: <3952.1255191642@critter.freebsd.dk>

In message <p06240800c6f64b0a89ae@[192.168.1.212]>, Joe Gwinn writes:

>By definition, POSIX Time is closer to TAI than to UTC, 

Uhm, no even close.

POSIX time is UTC pretending leap-seconds do not exist.

-- 
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 imp at bsdimp.com  Sat Oct 10 12:24:25 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 10 Oct 2009 10:24:25 -0600 (MDT)
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <4AD0A3D9.2080403@rubidium.dyndns.org>
References: <4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
Message-ID: <20091010.102425.477146992.imp@bsdimp.com>

In message: <4AD0A3D9.2080403 at rubidium.dyndns.org>
            Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: Joe,
: 
: Joe Gwinn wrote:
: > At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
: >> M. Warner Losh wrote:
: >>> In message: <4ACFF759.3090903 at rubidium.dyndns.org>
: >>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: >>> : M. Warner Losh wrote:
: >>> : > In message: 
: >>> <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
: >>> : >             Jonathan Natale <jnatale at juniper.net> writes:
: >>> : > : AFAIK, routers also just re-sych.  The OS's are not capable of
: >>> : > : xx:xx:60 time.  For reading router logs this is fine in most cases
: >>> : > : which is all NTP is really for.  I don't think they simply step 
: >>> the
: >>> : > : time, I am pretty sure they do tweak the freq.  I could be 
: >>> wrong and
: >>> : > : I am NOT representing Juniper here, just my thoughts. :-)
: >>> : > : > FreeBSD will cope with the xx:xx:60 second correctly, 
: >>> assuming it is
: >>> : > told about the leapsecond soon enough.  Not all other parts of the
: >>> : > system can cope with the xx:xx:60, but that's a posix time_t
: >>> : > limitation that you can't do anything about[*].
: >>> : > : > Warner
: >>> : > : > [*] The 'right' timezone files attempt to do things 
: >>> correctly, but in
: >>> : > doing so they break time_t definition...
: >>> : : I assumed you meant to say that it breaks the POSIX time_t 
: >>> definition.
: >>>
: >>> Yes.  The most current time_t definition is the one codified by POSIX.
: >>> Older standards are fuzzier about what time_t really means.
: >>
: >> Indeed. As there exist several time_t definitions, I wanted to make 
: >> sure you was refering to the POSIX mapping of UTC time into time_t, 
: >> which forms an "interesting" timescale of its own, almost but not 
: >> close enough to UTC.
: > 
: > By definition, POSIX Time is closer to TAI than to UTC, but in practice 
: > time in POSIX-compliant computers is usually NTP steered to approximate 
: > UTC (most common) or to GPS System Time (where leapseconds cannot be 
: > tolerated).
: 
: As the text of subclause 4.14 of the POSIX base standard defines it, it 
: is based on "Coordinated Universal Time" and the "name" is mapped into 
: seconds as defined by the mapping function. This makes it follow UTC 
: while maintaining the mental feel of being TAI-based without any leap 
: seconds, but it is closer to UTC as only occasionally (on the leap 
: second second) differs by a second during a second while it has a so far 
: constantly increasing difference to TAI. So on average it is much closer 
: to UTC than TAI.
: 
: So I respectfully disagree with your statement that POSIX Time is closer 
: to TAI than UTC. I think that it is closer to UTC and that the NTP 
: steering honour the POSIX UTC to time_t mapping.
: 
: A user wishing to display correct UTC time during leap-second would need 
: to querry the NTP  kernel over the provided interface to recover the 
: extra information, which is possible when the NTP has the necessary 
: leapsecond information and is enabled.
: 
: I had the distinct memory that we discussed this indepth some time ago 
: both on and off list(s).

Yes.  The original time_t (and long before it) definition was a bit
vague.  It was written as "Seconds since Jan 1, 1970 GMT," but in
practice it either had so large an error that the exact definition was
irrelevant, or it was implemented as POSIX time_t is today.

POSIX is worse.  You'd think you could display the leap second by
setting a struct tm's tm_sec to 60, but POSIX specifies that this
value be normalized before display, so you get the first second of the
next day twice if you don't roll your own routines...

Warner

From magnus at rubidium.dyndns.org  Sat Oct 10 12:56:00 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sat, 10 Oct 2009 18:56:00 +0200
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <20091010.102425.477146992.imp@bsdimp.com>
References: <4AD08C12.4090100@rubidium.dyndns.org>	<p06240800c6f64b0a89ae@[192.168.1.212]>	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<20091010.102425.477146992.imp@bsdimp.com>
Message-ID: <4AD0BCA0.7020100@rubidium.dyndns.org>

M. Warner Losh wrote:
> In message: <4AD0A3D9.2080403 at rubidium.dyndns.org>
>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
> : Joe,
> : 
> : Joe Gwinn wrote:
> : > At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
> : >> M. Warner Losh wrote:
> : >>> In message: <4ACFF759.3090903 at rubidium.dyndns.org>
> : >>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
> : >>> : M. Warner Losh wrote:
> : >>> : > In message: 
> : >>> <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
> : >>> : >             Jonathan Natale <jnatale at juniper.net> writes:
> : >>> : > : AFAIK, routers also just re-sych.  The OS's are not capable of
> : >>> : > : xx:xx:60 time.  For reading router logs this is fine in most cases
> : >>> : > : which is all NTP is really for.  I don't think they simply step 
> : >>> the
> : >>> : > : time, I am pretty sure they do tweak the freq.  I could be 
> : >>> wrong and
> : >>> : > : I am NOT representing Juniper here, just my thoughts. :-)
> : >>> : > : > FreeBSD will cope with the xx:xx:60 second correctly, 
> : >>> assuming it is
> : >>> : > told about the leapsecond soon enough.  Not all other parts of the
> : >>> : > system can cope with the xx:xx:60, but that's a posix time_t
> : >>> : > limitation that you can't do anything about[*].
> : >>> : > : > Warner
> : >>> : > : > [*] The 'right' timezone files attempt to do things 
> : >>> correctly, but in
> : >>> : > doing so they break time_t definition...
> : >>> : : I assumed you meant to say that it breaks the POSIX time_t 
> : >>> definition.
> : >>>
> : >>> Yes.  The most current time_t definition is the one codified by POSIX.
> : >>> Older standards are fuzzier about what time_t really means.
> : >>
> : >> Indeed. As there exist several time_t definitions, I wanted to make 
> : >> sure you was refering to the POSIX mapping of UTC time into time_t, 
> : >> which forms an "interesting" timescale of its own, almost but not 
> : >> close enough to UTC.
> : > 
> : > By definition, POSIX Time is closer to TAI than to UTC, but in practice 
> : > time in POSIX-compliant computers is usually NTP steered to approximate 
> : > UTC (most common) or to GPS System Time (where leapseconds cannot be 
> : > tolerated).
> : 
> : As the text of subclause 4.14 of the POSIX base standard defines it, it 
> : is based on "Coordinated Universal Time" and the "name" is mapped into 
> : seconds as defined by the mapping function. This makes it follow UTC 
> : while maintaining the mental feel of being TAI-based without any leap 
> : seconds, but it is closer to UTC as only occasionally (on the leap 
> : second second) differs by a second during a second while it has a so far 
> : constantly increasing difference to TAI. So on average it is much closer 
> : to UTC than TAI.
> : 
> : So I respectfully disagree with your statement that POSIX Time is closer 
> : to TAI than UTC. I think that it is closer to UTC and that the NTP 
> : steering honour the POSIX UTC to time_t mapping.
> : 
> : A user wishing to display correct UTC time during leap-second would need 
> : to querry the NTP  kernel over the provided interface to recover the 
> : extra information, which is possible when the NTP has the necessary 
> : leapsecond information and is enabled.
> : 
> : I had the distinct memory that we discussed this indepth some time ago 
> : both on and off list(s).
> 
> Yes.  The original time_t (and long before it) definition was a bit
> vague.  It was written as "Seconds since Jan 1, 1970 GMT," but in
> practice it either had so large an error that the exact definition was
> irrelevant, or it was implemented as POSIX time_t is today.

The initial systems used the 60 Hz or 50 Hz of the power grid.

> POSIX is worse.  You'd think you could display the leap second by
> setting a struct tm's tm_sec to 60, but POSIX specifies that this
> value be normalized before display, so you get the first second of the
> next day twice if you don't roll your own routines...

There are ways in which the POSIX could be extended to allow for propper 
time, but time_t would probably have to stay the same. The POSIX time_t 
fits the needs of embedded systems or various servers and clients having 
no need for propper UTC, but when you need it you need to look further, 
and that would also result in the need to correct all related 
applications. But then, that is the price one needs to play since time_t 
is neither TAI or UTC.

Cheers,
Magnus

From sla at ucolick.org  Sat Oct 10 12:49:44 2009
From: sla at ucolick.org (Steve Allen)
Date: Sat, 10 Oct 2009 09:49:44 -0700
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <20091010.102425.477146992.imp@bsdimp.com>
References: <4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<20091010.102425.477146992.imp@bsdimp.com>
Message-ID: <66BACC53-4275-4356-8CD2-925BF5791059@ucolick.org>

POSIX time is simply self-inconsistent as defined.
Different commentators with different preferences cue on different
aspects of the inconsistency.

I prefer to point out that no interpretation of POSIX time can
be consistent with the legal time standard of all nations which
was in contemporary use, as in the javascript here
http://www.ucolick.org/~sla/leapsecs/epochtime.html

As such I do not expect that international standards bodies
will ever be able to produce anything other than a compromise
interpretation.

--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  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  Sat Oct 10 13:33:38 2009
From: sla at ucolick.org (Steve Allen)
Date: Sat, 10 Oct 2009 10:33:38 -0700
Subject: [LEAPSECS] proliferation of scales
Message-ID: <20091010173338.GA11382@ucolick.org>

While reviewing the results of CGSIC 49 I was surprised by part of
Lewandowski's summary.
http://www.navcen.uscg.gov/cgsic/meetings/49thmeeting/Reports/%5B39%5DTiming_WL_General.pdf
He includes Recommendation CCTF 4 (2009) from the meeting last June.

That recommends the CIPM get the CGPM to adopt the ITRS, thus giving
that terrestrial reference system standing as not just scientific, but
intergovernmental.

ITRS is defined such that its units of length, time, mass are measured
in the GCRS, a relativistic reference frame co-moving with the
geocenter, but not affected by the mass or rotation of the earth.
Therefore the scale of SI metrology in ITRS is not equal to the scale
of SI metrology used by denizens on the surface of the earth.  The
rotation and gravity mean that SI seconds in ITRS tick faster (they
are seconds of TCG, not TT), and SI meters in ITRS are shorter.

The various versions of ITRF through the years are the realized form
of ITRS.  A look at the IERS Conventions shows that the first few
instances of ITRF were expressed in the so-called "TCG units", but
later they changed to "TT units" in acknowledgement that the real
chronometers and rulers of all the agencies contributing data were
located on the surface of the earth, not in some idealized co-moving
reference frame.

So if I take this too seriously I suppose that the CCTF just
recommended not only that GPS switch from WGS-84 to ITRF, but that
everyone change the scale of their units of measurement.

The confusion is deeper than that.  The IERS Conventions document uses
the terms "TT units" and "TCG units".  When I last checked the
literature I saw Sergei Klioner writing papers which challenge the
terminology of "TT units" and "TCG units" (and "TCB units", for the
solar system ephemerides).  So not only is there confusion about the
scale of measurement, but also about the terminolgy which underlies
human comprehension of the distinctions being measured.

I guess we live in interesting times, and I remain unclear about
how changing UTC to omit leap seconds will reduce confusion.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From phk at phk.freebsd.dk  Sat Oct 10 14:35:16 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sat, 10 Oct 2009 18:35:16 +0000
Subject: [LEAPSECS] POSIX Time
In-Reply-To: Your message of "Sat, 10 Oct 2009 10:24:25 CST."
	<20091010.102425.477146992.imp@bsdimp.com> 
Message-ID: <4317.1255199716@critter.freebsd.dk>

In message <20091010.102425.477146992.imp at bsdimp.com>, "M. Warner Losh" writes:

>Yes.  The original time_t (and long before it) definition was a bit
>vague.  It was written as "Seconds since Jan 1, 1970 GMT," but in
>practice it either had so large an error that the exact definition was
>irrelevant, or it was implemented as POSIX time_t is today.

Back then, the PDP's had a register that counted cycles on the mains
which was used for timekeeping.

At least anectotal evidence indicates that in several geographices
the first handful of leap-seconds were "smoothed out" in the mains,
because synchronous motor clocks were in widespread use by the
power-plants.

In the nordic net-group, all leapseconds in the 1980'ies were done
this way in the grid.  Af that deregulation, and because of
quartz-clocks, nobody thought it was necessary to make the number
of cycles look right when measured over a year any longer.

-- 
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 joegwinn at comcast.net  Sat Oct 10 19:03:25 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sat, 10 Oct 2009 19:03:25 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <4AD0A3D9.2080403@rubidium.dyndns.org>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
	<4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
Message-ID: <p06240801c6f6bd0c4223@[192.168.1.212]>

Magnus,

At 5:10 PM +0200 10/10/09, Magnus Danielson wrote:
>Joe,
>
>Joe Gwinn wrote:
>>At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
>>>M. Warner Losh wrote:
>>>>In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>>>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
>>>>: M. Warner Losh wrote:
>>>>: > In message: 
>>>><13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
>>>>: >             Jonathan Natale <jnatale at juniper.net> writes:
>>>>: > : AFAIK, routers also just re-sych.  The OS's are not capable of
>>>>: > : xx:xx:60 time.  For reading router logs this is fine in most cases
>>>>: > : which is all NTP is really for.  I don't think they simply step the
>>>>: > : time, I am pretty sure they do tweak the freq.  I could be wrong and
>>>>: > : I am NOT representing Juniper here, just my thoughts. :-)
>>>>: > : > FreeBSD will cope with the xx:xx:60 second correctly, 
>>>>assuming it is
>>>>: > told about the leapsecond soon enough.  Not all other parts of the
>>>>: > system can cope with the xx:xx:60, but that's a posix time_t
>>>>: > limitation that you can't do anything about[*].
>>>>: > : > Warner
>>>>: > : > [*] The 'right' timezone files attempt to do things 
>>>>correctly, but in
>>>>: > doing so they break time_t definition...
>>>>: : I assumed you meant to say that it breaks the POSIX time_t definition.
>>>>
>>>>Yes.  The most current time_t definition is the one codified by POSIX.
>>>>Older standards are fuzzier about what time_t really means.
>>>
>>>Indeed. As there exist several time_t definitions, I wanted to 
>>>make sure you was refering to the POSIX mapping of UTC time into 
>>>time_t, which forms an "interesting" timescale of its own, almost 
>>>but not close enough to UTC.
>>
>>By definition, POSIX Time is closer to TAI than to UTC, but in 
>>practice time in POSIX-compliant computers is usually NTP steered 
>>to approximate UTC (most common) or to GPS System Time (where 
>>leapseconds cannot be tolerated).
>
>As the text of subclause 4.14 of the POSIX base standard defines it, 
>it is based on "Coordinated Universal Time" and the "name" is mapped 
>into seconds as defined by the mapping function. This makes it 
>follow UTC while maintaining the mental feel of being TAI-based 
>without any leap seconds, but it is closer to UTC as only 
>occasionally (on the leap second second) differs by a second during 
>a second while it has a so far constantly increasing difference to 
>TAI. So on average it is much closer to UTC than TAI.
>
>So I respectfully disagree with your statement that POSIX Time is 
>closer to TAI than UTC. I think that it is closer to UTC and that 
>the NTP steering honour the POSIX UTC to time_t mapping.

Be careful to distinguish "broken down time" (an ascii string that 
resembles UTC) from the underlying clock (two 32-bit integers that 
are supposed to count SI seconds and nanoseconds since the POSIX 
Epoch).

If you read the POSIX standard, you will find that the length of the 
day is defined as exactly 86,400 seconds, no more no less.  So, leap 
seconds are by definition forbidden.  This was the intent of the 
committee.

Another common source of confusion is that the POSIX Epoch is an 
instant defined in UTC terms, but one can define an instant in any 
timescale one wishes, and the instant may appear in all of them but 
belongs to none of them.

However, most people who care even a little about time use NTP to 
synchronize their computer's time to something, and by far the bulk 
of the relevant timeservers publish UTC, never mind the formal 
definition of POSIX Time.  So, in practice time on such systems is 
neither fish nor fowl, being neither TAI not UTC, instead being a 
mixture.


>A user wishing to display correct UTC time during leap-second would 
>need to querry the NTP  kernel over the provided interface to 
>recover the extra information, which is possible when the NTP has 
>the necessary leapsecond information and is enabled.

A tall order for sure, and one is completely at the mercy of the 
operating system kernel developers, who may be hazy on the details of 
time.

In the systems I have had a hand in, the computer clocks are 
synchronized to GPS System Time (because those systems cannot 
tolerate the discontinuities caused by leap seconds) and UTC is made 
by the application software only where needed when needed.


>I had the distinct memory that we discussed this in depth some time 
>ago both on and off list(s).

You've let our secret out!  Yes, it was in January 2009.

Joe Gwinn

From zefram at fysh.org  Sat Oct 10 19:22:16 2009
From: zefram at fysh.org (Zefram)
Date: Sun, 11 Oct 2009 00:22:16 +0100
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <p06240801c6f6bd0c4223@[192.168.1.212]>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
	<4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<p06240801c6f6bd0c4223@[192.168.1.212]>
Message-ID: <20091010232216.GP403@fysh.org>

Joe Gwinn wrote:
>If you read the POSIX standard, you will find that the length of the day 
>is defined as exactly 86,400 seconds, no more no less.

Not quite.  To be precise, the time_t value increases by exactly 86400
per day, *regardless of how long the day is*.  A POSIX time_t value is a
(lossy) transformation of a broken-down UTC time, *not* a linear count
of seconds.

>Another common source of confusion is that the POSIX Epoch is an instant 
>defined in UTC terms,

... and occurring at a time for which the present form of UTC is
undefined.  I don't think anyone actually attempts to apply the POSIX
time_t definition to pre-1972 (pre-leap-seconds) UTC.  De facto, Unix
timestamps of any significant age cannot be precisely related to UTC
(or TAI or any other precision time scale).  Historical time_t values
can at best only be interpreted as a transformation of vague UT, unusable
for sub-second absolute timing.  (Actually, you won't often see pre-1990
timestamps that are accurate to the minute, let alone precise enough to
distinguish between flavours of UT.)

>> A user wishing to display correct UTC time during leap-second would  
>> need to querry the NTP  kernel
>
>A tall order for sure,

The ntp_adjtime() interface is semi-standard for Unix systems.
Interpreting all the variations of the interface is a bit of a task.
In the future the OS variants in how to do this should all be hidden by
uniform higher-level interfaces.  That's the intent of my Perl module
Time::UTC::Now, <http://search.cpan.org/perldoc?Time::UTC::Now>.

-zefram

From joegwinn at comcast.net  Sat Oct 10 19:51:22 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sat, 10 Oct 2009 19:51:22 -0400
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <66BACC53-4275-4356-8CD2-925BF5791059@ucolick.org>
References: <4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<20091010.102425.477146992.imp@bsdimp.com>
	<66BACC53-4275-4356-8CD2-925BF5791059@ucolick.org>
Message-ID: <p06240803c6f6c5eb5658@[192.168.1.212]>

At 9:49 AM -0700 10/10/09, Steve Allen wrote:
>POSIX time is simply self-inconsistent as defined.
>Different commentators with different preferences cue on different
>aspects of the inconsistency.

POSIX Time as defined is self-consistent, but for various mostly good 
reasons isn't what many people want, and there were protracted time 
wars in the POSIX committee about what POSIX Time should and should 
not be.  There were many partisans, each loudly and intolerantly 
proclaiming that only they possessed the One True Clock, while 
ignoring the problems that any POSIX timescale must solve to be 
accepted.

The partisan fighting soon exhausted the Committee, who then threw 
their hands up and mostly stuck with a slight cleanup of the prior 
standard wording.


>I prefer to point out that no interpretation of POSIX time can
>be consistent with the legal time standard of all nations which
>was in contemporary use, as in the javascript here
>http://www.ucolick.org/~sla/leapsecs/epochtime.html

I can well believe this.  POSIX Time as used is neither TAI nor UTC. 
In practice, this inconsistency matters little -- most people just 
use NTP-distributed UTC from GPS receivers and get on with life.


>As such I do not expect that international standards bodies
>will ever be able to produce anything other than a compromise
>interpretation.

The POSIX Committee threw the partisans out for a simple reason - the 
partisans were screaming at each other and at the committee members 
in timetalk, an obscure foreign language, and very few in the 
Committee could even follow the arguments, let alone decide who to 
agree with.  Most committee members are experts in UNIX/Linux 
operating system internals, know little to nothing of time, and have 
little motivation to become experts in time.  And they had bigger 
fish to fry.  So the Committee was forced to punt.

If the timefolk were to have their fights and bury their dead in 
private, and only then have the survivors present a unified proposal 
to the Committee, it might be possible to get the definition of POSIX 
Time updated.  The next opportunity to change is in about three 
years, when the development of the next revision of the POSIX 
standard will be undertaken.

Joe Gwinn

Vice Chairman, POSIX
Chairman, POSIX Realtime Subcommittee


>--
>Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
>UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
>University of California  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
>http://six.pairlist.net/mailman/listinfo/leapsecs


From joegwinn at comcast.net  Sat Oct 10 20:04:05 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sat, 10 Oct 2009 20:04:05 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <20091010232216.GP403@fysh.org>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
	<4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<p06240801c6f6bd0c4223@[192.168.1.212]> <20091010232216.GP403@fysh.org>
Message-ID: <p06240804c6f6cee17012@[192.168.1.212]>

At 12:22 AM +0100 10/11/09, Zefram wrote:
>Joe Gwinn wrote:
>>If you read the POSIX standard, you will find that the length of the day
>>is defined as exactly 86,400 seconds, no more no less.
>
>Not quite.  To be precise, the time_t value increases by exactly 86400
>per day, *regardless of how long the day is*.  A POSIX time_t value is a
>(lossy) transformation of a broken-down UTC time, *not* a linear count
>of seconds.

While in actual use you are correct or correct enough, the actual 
definition is as I stated.  One must read the words as they are on 
the page, without assumptions about common implementations.


>  >Another common source of confusion is that the POSIX Epoch is an instant
>>defined in UTC terms,
>
>... and occurring at a time for which the present form of UTC is
>undefined.  I don't think anyone actually attempts to apply the POSIX
>time_t definition to pre-1972 (pre-leap-seconds) UTC.  De facto, Unix
>timestamps of any significant age cannot be precisely related to UTC
>(or TAI or any other precision time scale).  Historical time_t values
>can at best only be interpreted as a transformation of vague UT, unusable
>for sub-second absolute timing.  (Actually, you won't often see pre-1990
>timestamps that are accurate to the minute, let alone precise enough to
>distinguish between flavours of UT.)

All kinda true, but for the intended use of POSIX Time, the errors 
are not significant bu the relevant users.  For instance, the UTC 
definition of the POSIX Epoch (originally defined in terms of GMT) is 
off by about 80 microseconds (if memory serves).


>  >> A user wishing to display correct UTC time during leap-second would 
>>>  need to querry the NTP  kernel
>>
>>A tall order for sure,
>
>The ntp_adjtime() interface is semi-standard for Unix systems.
>Interpreting all the variations of the interface is a bit of a task.
>In the future the OS variants in how to do this should all be hidden by
>uniform higher-level interfaces.  That's the intent of my Perl module
>Time::UTC::Now, <http://search.cpan.org/perldoc?Time::UTC::Now>.

The ntp_adjtime() interface is almost standard for sure, but how the 
operating system kernel implements it is all over the map.  One 
method is to track the error, and when it exceeds 0.5 mS, yank the 
clock in the opposite direction by 1.0 mS; this jump occurs every 100 
seconds or so.

An 80 microsecond error would be swamped, which is one reason the 
POSIX Committee didn't worry about the GMT-UTC delta error in the 
definition of the Epoch.

Nor is there an "NTP kernel" per se.  It's the operating system 
kernel that implements ntp_adjtime(), and the NTP daemon (a bit of 
application code) calls on adjtime to steer the local computer clock.

Joe Gwinn

From imp at bsdimp.com  Sun Oct 11 00:18:01 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 10 Oct 2009 22:18:01 -0600 (MDT)
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <p06240804c6f6cee17012@[192.168.1.212]>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>
	<20091010232216.GP403@fysh.org>
	<p06240804c6f6cee17012@[192.168.1.212]>
Message-ID: <20091010.221801.1723160031.imp@bsdimp.com>

In message: <p06240804c6f6cee17012@[192.168.1.212]>
            Joe Gwinn <joegwinn at comcast.net> writes:
: >  >Another common source of confusion is that the POSIX Epoch is an instant
: >>defined in UTC terms,
: >
: >... and occurring at a time for which the present form of UTC is
: >undefined.  I don't think anyone actually attempts to apply the POSIX
: >time_t definition to pre-1972 (pre-leap-seconds) UTC.  De facto, Unix
: >timestamps of any significant age cannot be precisely related to UTC
: >(or TAI or any other precision time scale).  Historical time_t values
: >can at best only be interpreted as a transformation of vague UT, unusable
: >for sub-second absolute timing.  (Actually, you won't often see pre-1990
: >timestamps that are accurate to the minute, let alone precise enough to
: >distinguish between flavours of UT.)
: 
: All kinda true, but for the intended use of POSIX Time, the errors 
: are not significant bu the relevant users.  For instance, the UTC 
: definition of the POSIX Epoch (originally defined in terms of GMT) is 
: off by about 80 microseconds (if memory serves).

Yes, time_t is usually talked about in terms of a fake UTC that never
existed: one where seconds were uniform and there were no steps in the
time scale.  Neither one of these were true.  About 2 seconds of UTC /
TAI divergence accumulated during 1970 and 1972.  The delta between
UTC and TAI was fixed at 10 at the start of 1972.  It on the order of
80ms shy of 8s on Jan 1, 1970, but I haven't done the math lately.

Time_t totally lacks the ability to accurately portray the rubber
seconds that pre-dated 1972.  And that bit of abnormality is usually
ignored for the sake of simplicity.

So in many ways UTC and time_t are only superficially similar things.
time_t is a half-assed attempt to do the right thing for time.  It
generally works for most people most of the time, but is wrong where
it doesn't match reality.

Warner

From magnus at rubidium.dyndns.org  Sun Oct 11 09:19:55 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 11 Oct 2009 15:19:55 +0200
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <p06240801c6f6bd0c4223@[192.168.1.212]>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>	<20091009.171343.-92838350.imp@bsdimp.com>	<4ACFF759.3090903@rubidium.dyndns.org>	<20091009.211452.961222257.imp@bsdimp.com>	<4AD08C12.4090100@rubidium.dyndns.org>	<p06240800c6f64b0a89ae@[192.168.1.212]>	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<p06240801c6f6bd0c4223@[192.168.1.212]>
Message-ID: <4AD1DB7B.10104@rubidium.dyndns.org>

Joe Gwinn wrote:
> Magnus,
> 
> At 5:10 PM +0200 10/10/09, Magnus Danielson wrote:
>> Joe,
>>
>> Joe Gwinn wrote:
>>> At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
>>>> M. Warner Losh wrote:
>>>>> In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>>>>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
>>>>> : M. Warner Losh wrote:
>>>>> : > In message: 
>>>>> <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>
>>>>> : >             Jonathan Natale <jnatale at juniper.net> writes:
>>>>> : > : AFAIK, routers also just re-sych.  The OS's are not capable of
>>>>> : > : xx:xx:60 time.  For reading router logs this is fine in most 
>>>>> cases
>>>>> : > : which is all NTP is really for.  I don't think they simply 
>>>>> step the
>>>>> : > : time, I am pretty sure they do tweak the freq.  I could be 
>>>>> wrong and
>>>>> : > : I am NOT representing Juniper here, just my thoughts. :-)
>>>>> : > : > FreeBSD will cope with the xx:xx:60 second correctly, 
>>>>> assuming it is
>>>>> : > told about the leapsecond soon enough.  Not all other parts of the
>>>>> : > system can cope with the xx:xx:60, but that's a posix time_t
>>>>> : > limitation that you can't do anything about[*].
>>>>> : > : > Warner
>>>>> : > : > [*] The 'right' timezone files attempt to do things 
>>>>> correctly, but in
>>>>> : > doing so they break time_t definition...
>>>>> : : I assumed you meant to say that it breaks the POSIX time_t 
>>>>> definition.
>>>>>
>>>>> Yes.  The most current time_t definition is the one codified by POSIX.
>>>>> Older standards are fuzzier about what time_t really means.
>>>>
>>>> Indeed. As there exist several time_t definitions, I wanted to make 
>>>> sure you was refering to the POSIX mapping of UTC time into time_t, 
>>>> which forms an "interesting" timescale of its own, almost but not 
>>>> close enough to UTC.
>>>
>>> By definition, POSIX Time is closer to TAI than to UTC, but in 
>>> practice time in POSIX-compliant computers is usually NTP steered to 
>>> approximate UTC (most common) or to GPS System Time (where 
>>> leapseconds cannot be tolerated).
>>
>> As the text of subclause 4.14 of the POSIX base standard defines it, 
>> it is based on "Coordinated Universal Time" and the "name" is mapped 
>> into seconds as defined by the mapping function. This makes it follow 
>> UTC while maintaining the mental feel of being TAI-based without any 
>> leap seconds, but it is closer to UTC as only occasionally (on the 
>> leap second second) differs by a second during a second while it has a 
>> so far constantly increasing difference to TAI. So on average it is 
>> much closer to UTC than TAI.
>>
>> So I respectfully disagree with your statement that POSIX Time is 
>> closer to TAI than UTC. I think that it is closer to UTC and that the 
>> NTP steering honour the POSIX UTC to time_t mapping.
> 
> Be careful to distinguish "broken down time" (an ascii string that 
> resembles UTC) from the underlying clock (two 32-bit integers that are 
> supposed to count SI seconds and nanoseconds since the POSIX Epoch).

This is why I write "POSIX time_t" rather than "POSIX time" to start 
with, to indicate that I mean the integer number value.

> If you read the POSIX standard, you will find that the length of the day 
> is defined as exactly 86,400 seconds, no more no less.  So, leap seconds 
> are by definition forbidden.  This was the intent of the committee.

I fully recognice this fact and see the POSIX time_t to be defined in 
such a way, yes.

> Another common source of confusion is that the POSIX Epoch is an instant 
> defined in UTC terms, but one can define an instant in any timescale one 
> wishes, and the instant may appear in all of them but belongs to none of 
> them.

You can use any timescale of choice, but the definition actually brings 
in UTC explicitly, and that is not a random timescale. Had the selection 
been TAI (or a suitable shift of it) it would have solved alot of 
problems, as relative measures between time_t would work well and 
absolute time stamps througout would be consistent and the issue of 
leapseconds would be hidden in the presentation into broken down time as 
libc performs it. If the text was not using the wording relating to UTC 
the issue would be quite different.

> However, most people who care even a little about time use NTP to 
> synchronize their computer's time to something, and by far the bulk of 
> the relevant timeservers publish UTC, never mind the formal definition 
> of POSIX Time.  So, in practice time on such systems is neither fish nor 
> fowl, being neither TAI not UTC, instead being a mixture.

NTP honour the UTC to time_t mapping. It does not give the correct 
23:59:60 reading thought, as the POSIX time_t system does not allow that.

>> A user wishing to display correct UTC time during leap-second would 
>> need to querry the NTP  kernel over the provided interface to recover 
>> the extra information, which is possible when the NTP has the 
>> necessary leapsecond information and is enabled.
> 
> A tall order for sure, and one is completely at the mercy of the 
> operating system kernel developers, who may be hazy on the details of time.
> 
> In the systems I have had a hand in, the computer clocks are 
> synchronized to GPS System Time (because those systems cannot tolerate 
> the discontinuities caused by leap seconds) and UTC is made by the 
> application software only where needed when needed.

That will work. I have no trouble with using a continous scale at the 
core, it just happends to be that I don't intereprent the POSIX time_t 
definition to provide that, it provides to me a time which looks 
continous, but there is occasional hickups if you follow the definition.

To be clear, within the POSIX time_t system, days is exactly 86400 
seconds long, and within that context broken down time and compound time 
is consistent. The problem lies in how the defined mapping from UTC to 
time_t is done, as the UTC broken down time (still) includes leap 
seconds. The UTC reading 23:59:60 will be a legal UTC name which still 
needs to be converted into POSIX time_t and when it is, the 00:00:00 
second occurs twice. This is what the definition means, as POSIX can't 
rule out the legal UTC leap second readings.

If you don't care about the fuzziness about not knowing which of these 
two seconds something happend or that a time-difference over a leap 
second may become 1 second longer than intended, then configuring an NTP 
client or hooking a GPS receiver with UTC will not be much of a deal.

Trouble is when systems needs correct time from ground up and also needs 
to follow propper UTC. Then you need to repair it from ground up.

If the core time was say GPS time based (still maintaining the POSIX 
epoch at or near 1970-1-1 00:00:00 GMT/UTC, the GPS epoch is a decade 
later) then broken down time would need to make leap second corrections, 
but that would work fairly well, as time_t would be strict 86400 second 
based but actually count the leap-seconds properly.

>> I had the distinct memory that we discussed this in depth some time 
>> ago both on and off list(s).
> 
> You've let our secret out!  Yes, it was in January 2009.

Right. Not meant to expose you or any ideas in a bad way. Sorry.

Cheers,
Magnus

From joegwinn at comcast.net  Sun Oct 11 10:52:57 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sun, 11 Oct 2009 10:52:57 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <4AD1DB7B.10104@rubidium.dyndns.org>
References: <13205C286662DE4387D9AF3AC30EF456AFA8697A05@EMBX01-WF.jnpr.net>
	<20091009.171343.-92838350.imp@bsdimp.com>
	<4ACFF759.3090903@rubidium.dyndns.org>
	<20091009.211452.961222257.imp@bsdimp.com>
	<4AD08C12.4090100@rubidium.dyndns.org>
	<p06240800c6f64b0a89ae@[192.168.1.212]>
	<4AD0A3D9.2080403@rubidium.dyndns.org>
	<p06240801c6f6bd0c4223@[192.168.1.212]>
	<4AD1DB7B.10104@rubidium.dyndns.org>
Message-ID: <p06240805c6f79d590aaa@[192.168.1.212]>

At 3:19 PM +0200 10/11/09, Magnus Danielson wrote:
>Joe Gwinn wrote:
>>Magnus,
>>
>>At 5:10 PM +0200 10/10/09, Magnus Danielson wrote:
>>>Joe,
>>>
>>>Joe Gwinn wrote:
>>>>At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:
>>>>>M. Warner Losh wrote:
>>>>>>In message: <4ACFF759.3090903 at rubidium.dyndns.org>
>>>>>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:
>>>>>>[snip]
>>>>>>Yes.  The most current time_t definition is the one codified by POSIX.
>>>>>>Older standards are fuzzier about what time_t really means.
>>>>>
>>>>>Indeed. As there exist several time_t definitions, I wanted to 
>>>>>make sure you was refering to the POSIX mapping of UTC time into 
>>>>>time_t, which forms an "interesting" timescale of its own, 
>>>>>almost but not close enough to UTC.
>>>>
>>>>By definition, POSIX Time is closer to TAI than to UTC, but in 
>>>>practice time in POSIX-compliant computers is usually NTP steered 
>>>>to approximate UTC (most common) or to GPS System Time (where 
>>>>leapseconds cannot be tolerated).
>>>
>>>As the text of subclause 4.14 of the POSIX base standard defines 
>>>it, it is based on "Coordinated Universal Time" and the "name" is 
>>>mapped into seconds as defined by the mapping function. This makes 
>>>it follow UTC while maintaining the mental feel of being TAI-based 
>>>without any leap seconds, but it is closer to UTC as only 
>>>occasionally (on the leap second second) differs by a second 
>>>during a second while it has a so far constantly increasing 
>>>difference to TAI. So on average it is much closer to UTC than TAI.
>>>
>>>So I respectfully disagree with your statement that POSIX Time is 
>>>closer to TAI than UTC. I think that it is closer to UTC and that 
>>>the NTP steering honour the POSIX UTC to time_t mapping.
>>
>>Be careful to distinguish "broken down time" (an ascii string that 
>>resembles UTC) from the underlying clock (two 32-bit integers that 
>>are supposed to count SI seconds and nanoseconds since the POSIX 
>>Epoch).
>
>This is why I write "POSIX time_t" rather than "POSIX time" to start 
>with, to indicate that I mean the integer number value.

OK, but there are different forms of the same timescale.


>>If you read the POSIX standard, you will find that the length of 
>>the day is defined as exactly 86,400 seconds, no more no less.  So, 
>>leap seconds are by definition forbidden.  This was the intent of 
>>the committee.
>
>I fully recognice this fact and see the POSIX time_t to be defined 
>in such a way, yes.
>
>>Another common source of confusion is that the POSIX Epoch is an 
>>instant defined in UTC terms, but one can define an instant in any 
>>timescale one wishes, and the instant may appear in all of them but 
>>belongs to none of them.
>
>You can use any timescale of choice, but the definition actually 
>brings in UTC explicitly, and that is not a random timescale.

My point is that even though the POSIX timescale Epoch is defined in 
UTC, that does not make the POSIX timescale the same as UTC. 
Leapseconds are integral to UTC, and yet POSIX Time has no 
leapseconds.


>Had the selection been TAI (or a suitable shift of it) it would have 
>solved alot of problems, as relative measures between time_t would 
>work well and absolute time stamps througout would be consistent and 
>the issue of leapseconds would be hidden in the presentation into 
>broken down time as libc performs it. If the text was not using the 
>wording relating to UTC the issue would be quite different.

I completely agree.


>>However, most people who care even a little about time use NTP to 
>>synchronize their computer's time to something, and by far the bulk 
>>of the relevant timeservers publish UTC, never mind the formal 
>>definition of POSIX Time.  So, in practice time on such systems is 
>>neither fish nor fowl, being neither TAI not UTC, instead being a 
>>mixture.
>
>NTP honour the UTC to time_t mapping. It does not give the correct 
>23:59:60 reading thought, as the POSIX time_t system does not allow 
>that.

And with this too.


>>>A user wishing to display correct UTC time during leap-second 
>>>would need to querry the NTP  kernel over the provided interface 
>>>to recover the extra information, which is possible when the NTP 
>>>has the necessary leapsecond information and is enabled.
>>
>>A tall order for sure, and one is completely at the mercy of the 
>>operating system kernel developers, who may be hazy on the details 
>>of time.
>>
>>In the systems I have had a hand in, the computer clocks are 
>>synchronized to GPS System Time (because those systems cannot 
>>tolerate the discontinuities caused by leap seconds) and UTC is 
>>made by the application software only where needed when needed.
>
>That will work. I have no trouble with using a continous scale at 
>the core, it just happends to be that I don't intereprent the POSIX 
>time_t definition to provide that, it provides to me a time which 
>looks continous, but there is occasional hickups if you follow the 
>definition.

Well, if people actually followed the POSIX Time definition to the 
letter, there would be no hiccups.  But nobody follows the definition 
that strictly.  Except those who disseminate GPS System Time via NTP, 
thereby sidestepping the whole leapsecond problem.


>To be clear, within the POSIX time_t system, days are exactly 86400 
>seconds long, and within that context broken down time and compound 
>time is consistent. The problem lies in how the defined mapping from 
>UTC to time_t is done, as the UTC broken down time (still) includes 
>leap seconds. The UTC reading 23:59:60 will be a legal UTC name 
>which still needs to be converted into POSIX time_t and when it is, 
>the 00:00:00 second occurs twice. This is what the definition means, 
>as POSIX can't rule out the legal UTC leap second readings.

Sure POSIX can exclude leapseconds, as POSIX does not claim to be 
UTC.  If memory serves, POSIX specifically disclaims being UTC.


>If you don't care about the fuzziness about not knowing which of 
>these two seconds something happend or that a time-difference over a 
>leap second may become 1 second longer than intended, then 
>configuring an NTP client or hooking a GPS receiver with UTC will 
>not be much of a deal.
>
>Trouble is when systems needs correct time from ground up and also 
>needs to follow proper UTC. Then you need to repair it from the 
>ground up.

Yes.  This is exactly why some systems use NTP to distribute GPS System Time.


>If the core time was say GPS time based (still maintaining the POSIX 
>epoch at or near 1970-1-1 00:00:00 GMT/UTC; the GPS epoch is a 
>decade later) then broken down time would need to make leap second 
>corrections, but that would work fairly well, as time_t would be 
>strict 86400 second based but actually count the leap-seconds 
>properly.

That could work, if NTP and eventually the operating system kernels 
were changed to accommodate it.  This isn't impossible, but it isn't 
likely to be achieved quickly either.  But one must start to have any 
hope of finishing.


>>>I had the distinct memory that we discussed this in depth some 
>>>time ago both on and off list(s).
>>
>>You've let our secret out!  Yes, it was in January 2009.
>
>Right. Not meant to expose you or any ideas in a bad way. Sorry.

No secret and offence taken.  I was pulling your leg....

Joe Gwinn

From phk at phk.freebsd.dk  Sun Oct 11 11:08:49 2009
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Sun, 11 Oct 2009 15:08:49 +0000
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: Your message of "Sun, 11 Oct 2009 10:52:57 -0400."
	<p06240805c6f79d590aaa@[192.168.1.212]> 
Message-ID: <7197.1255273729@critter.freebsd.dk>

In message <p06240805c6f79d590aaa@[192.168.1.212]>, Joe Gwinn writes:

>My point is that even though the POSIX timescale Epoch is defined in 
>UTC, that does not make the POSIX timescale the same as UTC. 

I feel compelled to quote, at length, what The Open Group has to
say on this subject, since appearantly a number of people have
not actually read this stuff.

Please do so now, so we get a facts based discussion.

Poul-Henning

Epoch

Historically, the origin of UNIX system time was referred to as
"00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually
not a term acknowledged by the international standards community;
therefore, this term, "Epoch", is used to abbreviate the reference
to the actual standard, Coordinated Universal Time.


 A.4.14 Seconds Since the Epoch

Coordinated Universal Time (UTC) includes leap seconds. However,
in POSIX time (seconds since the Epoch), leap seconds are ignored
(not applied) to provide an easy and compatible method of computing
time differences. Broken-down POSIX time is therefore not necessarily
UTC, despite its appearance.

As of September 2000, 24 leap seconds had been added to UTC since
the Epoch, 1 January, 1970. Historically, one leap second is added
every 15 months on average, so this offset can be expected to grow
steadily with time.

Most systems' notion of "time" is that of a continuously increasing
value, so this value should increase even during leap seconds.
However, not only do most systems not keep track of leap seconds,
but most systems are probably not synchronized to any standard time
reference. Therefore, it is inappropriate to require that a time
represented as seconds since the Epoch precisely represent the
number of seconds between the referenced time and the Epoch.

It is sufficient to require that applications be allowed to treat
this time as if it represented the number of seconds between the
referenced time and the Epoch. It is the responsibility of the
vendor of the system, and the administrator of the system, to ensure
that this value represents the number of seconds between the
referenced time and the Epoch as closely as necessary for the
application being run on that system.

It is important that the interpretation of time names and seconds
since the Epoch values be consistent across conforming systems;
that is, it is important that all conforming systems interpret
"536457599 seconds since the Epoch" as 59 seconds, 59 minutes, 23
hours 31 December 1986, regardless of the accuracy of the system's
idea of the current time. The expression is given to ensure a
consistent interpretation, not to attempt to specify the calendar.
The relationship between tm_yday and the day of week, day of month,
and month is in accordance with the Gregorian calendar, and so is
not specified in POSIX.1.

Consistent interpretation of seconds since the Epoch can be critical
to certain types of distributed applications that rely on such
timestamps to synchronize events. The accrual of leap seconds in a
time standard is not predictable. The number of leap seconds since
the Epoch will likely increase. POSIX.1 is more concerned about the
synchronization of time between applications of astronomically short
duration.

Note that tm_yday is zero-based, not one-based, so the day number
in the example above is 364. Note also that the division is an
integer division (discarding remainder) as in the C language.

Note also that the meaning of gmtime(), localtime(), and mktime()
is specified in terms of this expression. However, the ISO C standard
computes tm_yday from tm_mday, tm_mon, and tm_year in mktime().
Because it is stated as a (bidirectional) relationship, not a
function, and because the conversion between month-day-year and
day-of-year dates is presumed well known and is also a relationship,
this is not a problem.

Implementations that implement time_t as a signed 32-bit integer
will overflow in 2038. The data size for time_t is as per the ISO
C standard definition, which is implementation-defined.

See also Epoch.

The topic of whether seconds since the Epoch should account for
leap seconds has been debated on a number of occasions, and each
time consensus was reached (with acknowledged dissent each time)
that the majority of users are best served by treating all days
identically. (That is, the majority of applications were judged to
assume a single length-as measured in seconds since the Epoch-for
all days. Thus, leap seconds are not applied to seconds since the
Epoch.) Those applications which do care about leap seconds can
determine how to handle them in whatever way those applications
feel is best. This was particularly emphasized because there was
disagreement about what the best way of handling leap seconds might
be. It is a practical impossibility to mandate that a conforming
implementation must have a fixed relationship to any particular
official clock (consider isolated systems, or systems performing
"reruns" by setting the clock to some arbitrary time).

Note that as a practical consequence of this, the length of a second
as measured by some external standard is not specified. This
unspecified second is nominally equal to an International System
(SI) second in duration. Applications must be matched to a system
that provides the particular handling of external time in the way
required by the application.

IEEE Std 1003.1-2001/Cor 2-2004, item XBD/TC2/D6/12 is applied,
making an editorial correction to the paragraph commencing "How any
changes to the value of seconds ...".


-- 
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 sla at ucolick.org  Sun Oct 11 11:38:04 2009
From: sla at ucolick.org (Steve Allen)
Date: Sun, 11 Oct 2009 08:38:04 -0700
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <7197.1255273729@critter.freebsd.dk>
References: <7197.1255273729@critter.freebsd.dk>
Message-ID: <6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>

I believe my additions will make it clear why the POSIX
community threw out the folks who did understand time.

On 2009 Oct 11, at 08:08, Poul-Henning Kamp wrote:
> Historically, the origin of UNIX system time was referred to as
> "00:00:00 GMT, January 1, 1970". Greenwich Mean Time is actually
> not a term acknowledged by the international standards community;
> therefore, this term, "Epoch", is used to abbreviate the reference
> to the actual standard, Coordinated Universal Time.

UTC, which at that point did not exist as a standard, but only as
a term informally employed by some employees of the various
national time service bureaus as they described the form of
time they were broadcasting.  That was an attempt to follow
the UT2 then specified by the CCIR Recommendation.  Further note
that UT2 itself was never described by a standard, only by the
annual equation in current use by the BIH, an equation which
changed at least once.

> Most systems' notion of "time" is that of a continuously increasing
> value, so this value should increase even during leap seconds.
> However, not only do most systems not keep track of leap seconds,
> but most systems are probably not synchronized to any standard time
> reference. Therefore, it is inappropriate to require that a time
> represented as seconds since the Epoch precisely represent the
> number of seconds between the referenced time and the Epoch.

Clearly this was the state of most computer time, and most old
time_t stamps do not correspond accurately to anything.
I doubt that this paragraph can still be taken seriously in
situations where multiple systems must agree with each other.
The "as closely as necessary" in the next paragraph now has
to deal with many systems which can't just ignore leaps.


> The expression is given to ensure a
> consistent interpretation, not to attempt to specify the calendar.

Ultimately it becomes impossible to demand seconds of uniform
length, 86400 in a day, and agreement with a calendar.

> POSIX.1 is more concerned about the
> synchronization of time between applications of astronomically short
> duration.

I would find it helpful for the preceding sentence to be
more clear about what they think they are favoring.

>  It is a practical impossibility to mandate that a conforming
> implementation must have a fixed relationship to any particular
> official clock (consider isolated systems, or systems performing
> "reruns" by setting the clock to some arbitrary time).

Again, POSIX is admitting that some sacred cow is being gored here.

> Note that as a practical consequence of this, the length of a second
> as measured by some external standard is not specified. This
> unspecified second is nominally equal to an International System
> (SI) second in duration. Applications must be matched to a system
> that provides the particular handling of external time in the way
> required by the application.

To me the above combination of 3 sentences means that a lot of
different behaviors can all be POSIX-conformant.

I do not see the number 86400 anywhere in that text.

--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  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  Sun Oct 11 11:50:59 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sun, 11 Oct 2009 11:50:59 -0400
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <20091010.221801.1723160031.imp@bsdimp.com>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>
	<20091010232216.GP403@fysh.org>	<p06240804c6f6cee17012@[192.168.1.212]>
	<20091010.221801.1723160031.imp@bsdimp.com>
Message-ID: <p06240806c6f7ac1d8070@[192.168.1.212]>

At 10:18 PM -0600 10/10/09, M. Warner Losh wrote:
>In message: <p06240804c6f6cee17012@[192.168.1.212]>
>             Joe Gwinn <joegwinn at comcast.net> writes:
>: >  >Another common source of confusion is that the POSIX Epoch is an instant
>: >>defined in UTC terms,
>: >
>: >... and occurring at a time for which the present form of UTC is
>: >undefined.  I don't think anyone actually attempts to apply the POSIX
>: >time_t definition to pre-1972 (pre-leap-seconds) UTC.  De facto, Unix
>: >timestamps of any significant age cannot be precisely related to UTC
>: >(or TAI or any other precision time scale).  Historical time_t values
>: >can at best only be interpreted as a transformation of vague UT, unusable
>: >for sub-second absolute timing.  (Actually, you won't often see pre-1990
>: >timestamps that are accurate to the minute, let alone precise enough to
>: >distinguish between flavours of UT.)
>:
>: All kinda true, but for the intended use of POSIX Time, the errors
>: are not significant bu the relevant users.  For instance, the UTC
>: definition of the POSIX Epoch (originally defined in terms of GMT) is
>: off by about 80 microseconds (if memory serves).
>
>Yes, time_t is usually talked about in terms of a fake UTC that never
>existed: one where seconds were uniform and there were no steps in the
>time scale.  Neither one of these were true.  About 2 seconds of UTC /
>TAI divergence accumulated during 1970 and 1972.  The delta between
>UTC and TAI was fixed at 10 at the start of 1972.  It on the order of
>80ms shy of 8s on Jan 1, 1970, but I haven't done the math lately.

It's a "fake UTC" only in that people try to make POSIX Time be UTC, 
despite the standard's explicit disclaiming of any such thing.


>Time_t totally lacks the ability to accurately portray the rubber
>seconds that pre-dated 1972.  And that bit of abnormality is usually
>ignored for the sake of simplicity.

The POSIX timescale is explicitly undefined before the Epoch.  This 
is no accident, because for the purpose of the POSIX timescale 
(originally only file modification timestamps), there was and is no 
reason to be able to define times before POSIX itself existed.

The expectation is that people needing to handle timescales before 
and/or unrelated to the POSIX timescale will do so in application 
code.  For example, an astronomer doing computations of time and 
motion handles time as a form of data, and does not expect local time 
on the workstation doing the computation to jump to the time in the 
data now being processed.


>So in many ways UTC and time_t are only superficially similar things.
>time_t is a half-assed attempt to do the right thing for time.  It
>generally works for most people most of the time, but is wrong where
>it doesn't match reality.

POSIX Time (time_t) solves the problems it was intended to solve, but 
may be half-assed in the context of problems that it was never 
intended to solve.  The issue is not that POSIX Time is right or 
wrong, but that it is misapplied.  Screwdrivers don't make very good 
chisels, and chisels don't make very good screwdrivers, even if each 
is the best of its kind.


Joe Gwinn

From magnus at rubidium.dyndns.org  Sun Oct 11 15:07:07 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Sun, 11 Oct 2009 21:07:07 +0200
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <p06240806c6f7ac1d8070@[192.168.1.212]>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>	<20091010232216.GP403@fysh.org>	<p06240804c6f6cee17012@[192.168.1.212]>	<20091010.221801.1723160031.imp@bsdimp.com>
	<p06240806c6f7ac1d8070@[192.168.1.212]>
Message-ID: <4AD22CDB.8050402@rubidium.dyndns.org>

Joe,

>> So in many ways UTC and time_t are only superficially similar things.
>> time_t is a half-assed attempt to do the right thing for time.  It
>> generally works for most people most of the time, but is wrong where
>> it doesn't match reality.
> 
> POSIX Time (time_t) solves the problems it was intended to solve, but 
> may be half-assed in the context of problems that it was never intended 
> to solve.  The issue is not that POSIX Time is right or wrong, but that 
> it is misapplied.  Screwdrivers don't make very good chisels, and 
> chisels don't make very good screwdrivers, even if each is the best of 
> its kind.

The trouble is that it is the only basic tool provided, it looks like 
"time" to most than a few and no directions was given to what needs to 
be done if propper time is needed. Being the wrong tool but the only 
tool, we get forced to use it anyway.

We still need to figure out a good way to resolve the issue and let 
there be a method by which it can be implemented.

Cheers,
Magnus

From joegwinn at comcast.net  Sun Oct 11 15:43:07 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sun, 11 Oct 2009 15:43:07 -0400
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <4AD22CDB.8050402@rubidium.dyndns.org>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>
	<20091010232216.GP403@fysh.org>	<p06240804c6f6cee17012@[192.168.1.212]>
	<20091010.221801.1723160031.imp@bsdimp.com>
	<p06240806c6f7ac1d8070@[192.168.1.212]>
	<4AD22CDB.8050402@rubidium.dyndns.org>
Message-ID: <p06240807c6f7e0b8d4f2@[192.168.1.212]>

At 9:07 PM +0200 10/11/09, Magnus Danielson wrote:
>Joe,
>
>>>So in many ways UTC and time_t are only superficially similar things.
>>>time_t is a half-assed attempt to do the right thing for time.  It
>>>generally works for most people most of the time, but is wrong where
>>>it doesn't match reality.
>>
>>POSIX Time (time_t) solves the problems it was intended to solve, 
>>but may be half-assed in the context of problems that it was never 
>>intended to solve.  The issue is not that POSIX Time is right or 
>>wrong, but that it is misapplied.  Screwdrivers don't make very 
>>good chisels, and chisels don't make very good screwdrivers, even 
>>if each is the best of its kind.
>
>The trouble is that it is the only basic tool provided, it looks 
>like "time" to most than a few and no directions was given to what 
>needs to be done if proper time is needed. Being the wrong tool but 
>the only tool, we get forced to use it anyway.

True enough, but the problem seems to be more the seeing of UTC where 
there is none than problems with what is in fact provided.

Actually, POSIX allows one to have multiple named clocks, but I don't 
know of any large platform vendor that has taken advantage of the 
option.


>We still need to figure out a good way to resolve the issue and let 
>there be a method by which it can be implemented.

Yes.  Here is my posting to the POSIX Committee (and Austin Group) on 
the requirements, summarizing debate up till then:

<http://www.opengroup.org/austin/mailarchives/austin-group-l/msg02131.html>


Joe Gwinn

From sla at ucolick.org  Sun Oct 11 16:02:47 2009
From: sla at ucolick.org (Steve Allen)
Date: Sun, 11 Oct 2009 13:02:47 -0700
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <p06240807c6f7e0b8d4f2@[192.168.1.212]>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>
	<20091010232216.GP403@fysh.org>	<p06240804c6f6cee17012@[192.168.1.212]>
	<20091010.221801.1723160031.imp@bsdimp.com>
	<p06240806c6f7ac1d8070@[192.168.1.212]>
	<4AD22CDB.8050402@rubidium.dyndns.org>
	<p06240807c6f7e0b8d4f2@[192.168.1.212]>
Message-ID: <548386CF-9A26-46D4-AE88-9A43F34634BC@ucolick.org>

On 2009 Oct 11, at 12:43, Joe Gwinn wrote:
> Here is my posting to the POSIX Committee (and Austin Group) on the  
> requirements, summarizing debate up till then:
>
> <http://www.opengroup.org/austin/mailarchives/austin-group-l/ 
> msg02131.html>


One other practical requirement exists as a result of currently
deployed solutions.

The value of time_t must have a simple correspondence to one
of the existing broadcast time scales.  For most ensembles of
systems that time scale has to be whatever time scale is specified
by the ITU-R, but as we have read, some ensembles of systems
do choose GPS time.

--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  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  Sun Oct 11 20:39:33 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Sun, 11 Oct 2009 18:39:33 -0600 (MDT)
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <4AD22CDB.8050402@rubidium.dyndns.org>
References: <20091010.221801.1723160031.imp@bsdimp.com>
	<p06240806c6f7ac1d8070@[192.168.1.212]>
	<4AD22CDB.8050402@rubidium.dyndns.org>
Message-ID: <20091011.183933.-617933537.imp@bsdimp.com>

In message: <4AD22CDB.8050402 at rubidium.dyndns.org>
            Magnus Danielson <magnus at rubidium.dyndns.org> writes:
: Joe,
: 
: >> So in many ways UTC and time_t are only superficially similar things.
: >> time_t is a half-assed attempt to do the right thing for time.  It
: >> generally works for most people most of the time, but is wrong where
: >> it doesn't match reality.
: > 
: > POSIX Time (time_t) solves the problems it was intended to solve, but 
: > may be half-assed in the context of problems that it was never intended 
: > to solve.  The issue is not that POSIX Time is right or wrong, but that 
: > it is misapplied.  Screwdrivers don't make very good chisels, and 
: > chisels don't make very good screwdrivers, even if each is the best of 
: > its kind.
: 
: The trouble is that it is the only basic tool provided, it looks like 
: "time" to most than a few and no directions was given to what needs to 
: be done if propper time is needed. Being the wrong tool but the only 
: tool, we get forced to use it anyway.
: 
: We still need to figure out a good way to resolve the issue and let 
: there be a method by which it can be implemented.

The basic problem isn't that time_t made time keeping simple for most
users.  The basic problem is that it made it impossible to do
correctly for those users that care or are forced to care by statute.
Most programmers, when they first approach time_t, think that it is
the same thing as UTC so adopt it without thinking.  It is only when
the subtle differences come to light, say during conformance testing,
do people start to realize that it was the wrong tool.

To use a wood working analogy.  It is the wrong screwdriver for the
job.  This isn't a pounding screws analogy.  Rather, it is trying to
use the wrong flat blade to drive the screw.  It usually looks like it
works, but because the slot and the blade aren't well matched,
slippage can occur and mar the wood...  And by then, you <sometimes>
have to redo the whole piece because of the mismatch.

Warner

From joegwinn at comcast.net  Sun Oct 11 21:09:44 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sun, 11 Oct 2009 21:09:44 -0400
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <548386CF-9A26-46D4-AE88-9A43F34634BC@ucolick.org>
References: <p06240801c6f6bd0c4223@[192.168.1.212]>
	<20091010232216.GP403@fysh.org>	<p06240804c6f6cee17012@[192.168.1.212]>
	<20091010.221801.1723160031.imp@bsdimp.com>
	<p06240806c6f7ac1d8070@[192.168.1.212]>
	<4AD22CDB.8050402@rubidium.dyndns.org>
	<p06240807c6f7e0b8d4f2@[192.168.1.212]>
	<548386CF-9A26-46D4-AE88-9A43F34634BC@ucolick.org>
Message-ID: <p06240808c6f830196f89@[192.168.1.212]>

At 1:02 PM -0700 10/11/09, Steve Allen wrote:
>On 2009 Oct 11, at 12:43, Joe Gwinn wrote:
>>Here is my posting to the POSIX Committee (and Austin Group) on the 
>>requirements, summarizing debate up till then:
>>
>><http://www.opengroup.org/austin/mailarchives/austin-group-l/msg02131.html>
>
>
>One other practical requirement exists as a result of currently
>deployed solutions.
>
>The value of time_t must have a simple correspondence to one
>of the existing broadcast time scales.  For most ensembles of
>systems that time scale has to be whatever time scale is specified
>by the ITU-R, but as we have read, some ensembles of systems
>do choose GPS time.

I would phrase it slightly differently, that the new timescale must 
either be, or be easily derivable, from a widely disseminated 
timescale.  In practice, one's choices are UTC and GPS System Time.

Joe Gwinn

From sla at ucolick.org  Sun Oct 11 21:43:49 2009
From: sla at ucolick.org (Steve Allen)
Date: Sun, 11 Oct 2009 18:43:49 -0700
Subject: [LEAPSECS] systems that use GPS time
Message-ID: <6300EA17-840B-46BB-B665-378F65B6289D@ucolick.org>

Are there any folks who can comment on the operation of ensembles
of systems which use GPS time instead of UTC?

What are these systems?

What reasoning went into the choice of GPS time?
How did they reason so as to overcome the implicit mandates
that POSIX and  international standards place on the use of UTC?
Was the choice made because of an aversion to the handling of
leap seconds, or were there other concerns?

Do they use the standard zoneinfo files and just tolerate the fact
that the broken down time reports are off by a few seconds?
Or do they install custom zoneinfo files and get reports as true
UTC and/or local zone time?

--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064      http://www.ucolick.org/~sla/   Hgt +250 m


From zefram at fysh.org  Mon Oct 12 06:27:21 2009
From: zefram at fysh.org (Zefram)
Date: Mon, 12 Oct 2009 11:27:21 +0100
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>
References: <7197.1255273729@critter.freebsd.dk>
	<6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>
Message-ID: <20091012102721.GK20296@fysh.org>

Steve Allen wrote:
>I do not see the number 86400 anywhere in that text.

It appears in the equation (actually, a C expression) that was referenced
in that text.  PHK only quoted chunks of rationale there, not the main
text of the standard, where the equation appears.  It's the infamous
equation that originally failed to account for the century rule for
leap days.  The leap-day-correct version of the equation is

	tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
	(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
	((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

(The equation only applies where tm_year >= 70.  You'd need to amend
the divisions to sensibly handle earlier years.)  The accompanying
text (again, part of the main body of the standard) says that tm_sec,
tm_min, tm_hour, tm_yday, and tm_year together constitute a UTC label,
and there's nothing there saying that it doesn't apply to leap seconds.
The number appears again in the main text:

	As represented in seconds since the Epoch, each and every day
	shall be accounted for by exactly 86400 seconds.

which would be somewhat confusing, but the rationale (as PHK quoted)
makes clear that "seconds since the Epoch" isn't intended to be literally
a count of seconds.  Hence my earlier statement (and similar statement
in Wikipedia's [[Unix time]]) that time_t values increase by 86400 per
day regardless of actual day length.

-zefram

From sla at ucolick.org  Tue Oct 13 01:42:16 2009
From: sla at ucolick.org (Steve Allen)
Date: Mon, 12 Oct 2009 22:42:16 -0700
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <20091012102721.GK20296@fysh.org>
References: <7197.1255273729@critter.freebsd.dk>
	<6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>
	<20091012102721.GK20296@fysh.org>
Message-ID: <A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>

On 2009 Oct 12, at 03:27, Zefram wrote:
> The number appears again in the main text:
>
> 	As represented in seconds since the Epoch, each and every day
> 	shall be accounted for by exactly 86400 seconds.


Clearly that number is fiat, and not even some entity with the
authority of Pope Gregory could change it.  What remains is primarily
to interpret the meaning of the word "day".

In the time scales for TAI, LORAN-C, GPS, and now BST the word "day"
already has a meaning more clearly communicated by "atomic day".
The length of that "atomic day" is practically equivalent to the
"ephemeris day" of Gauss, as codified by Newcomb, as adopted by IAU,
and as realized by Markowitz, Essen, et al.

Resolution V of the 1884 International Meridian Conference defines
"day" to be a mean solar day.  To propose that "day" become redefined
as an "atomic day" is to propose the abrogation of the IMC.  It is
plainly outside the scope of the POSIX committee to implement such
a change.  They have to rely on the providers of time to give a
clear indication of what time_t should try to count.

--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064      http://www.ucolick.org/~sla/   Hgt +250 m


From magnus at rubidium.dyndns.org  Tue Oct 13 03:44:57 2009
From: magnus at rubidium.dyndns.org (Magnus Danielson)
Date: Tue, 13 Oct 2009 09:44:57 +0200
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
References: <7197.1255273729@critter.freebsd.dk>	<6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>	<20091012102721.GK20296@fysh.org>
	<A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
Message-ID: <4AD42FF9.1060105@rubidium.dyndns.org>

Steve Allen wrote:
> On 2009 Oct 12, at 03:27, Zefram wrote:
>> The number appears again in the main text:
>>
>>     As represented in seconds since the Epoch, each and every day
>>     shall be accounted for by exactly 86400 seconds.
> 
> 
> Clearly that number is fiat, and not even some entity with the
> authority of Pope Gregory could change it.  What remains is primarily
> to interpret the meaning of the word "day".
> 
> In the time scales for TAI, LORAN-C, GPS, and now BST the word "day"
> already has a meaning more clearly communicated by "atomic day".
> The length of that "atomic day" is practically equivalent to the
> "ephemeris day" of Gauss, as codified by Newcomb, as adopted by IAU,
> and as realized by Markowitz, Essen, et al.
> 
> Resolution V of the 1884 International Meridian Conference defines
> "day" to be a mean solar day.  To propose that "day" become redefined
> as an "atomic day" is to propose the abrogation of the IMC.  It is
> plainly outside the scope of the POSIX committee to implement such
> a change.  They have to rely on the providers of time to give a
> clear indication of what time_t should try to count.

The POSIX time_t day of 86400 seconds is kind of sacred. It is however a 
loose concept as the actual seconds of a day can be 86401 without too 
much fuzz for most apps, but the trouble is that applications that care 
needs to store the leapsecond counter with each timestamp in order to 
separate a timestamp occuring on a leapsecond from occuring the second 
before the timestamp. If the application cares about timestamps of 
files, then it depends on a rather large rewrite of the operating system 
to do the right thing. Thus, using broken down time in UTC to forcefeed 
time_t has complications to it. Letting time_t instead represent TAI has 
the issue of the timekeeper now must be able to provide TAI or GPS-time 
(which isn't TAI, but TAI-like) along with leapsecond data for UTC. That 
would mean the end of many GPS receivers being in use today, but change 
of a POSIS machine would be less for those that care, the TAI to UTC 
conversion can occur as a presentation factor just as with timezones.

So, letting time_t be TAI based and provide means for TAI to UTC 
conversion (for those vendors that care to provide it and those 
operators that include it) would work.

Boxes without external steering would not know if they where doing TAI 
or UTC stylish times... but the operator wou?d have set them to whatever 
suitable and they would tick away not bother about the details.

NTP based UTC forcefeeding of today would not use feed the leapsecond 
offset which would remain at 0 and the conversion would do the right 
thing. Updated NTP would decide if it can splitt the time, and when it 
can, it would feed the time_t in TAI and leapsecond offset with correct 
values.

Two boxes running different setups receiving an event and time-stamping 
them would not set the same time_t value, but broken down time could be 
made the same between the boxes. However, the error would be 30 some 
seconds off. Applications which needs to display this difference would 
need to bring the leapsecond offset in to compensate.

Sure, the time_t would only nominally be TAI-based (it would never be 
THE TAI), but would kind of work.

Cheers,
Magnus

From ashtongj at comcast.net  Tue Oct 13 12:21:27 2009
From: ashtongj at comcast.net (ashtongj)
Date: Tue, 13 Oct 2009 12:21:27 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
References: <7197.1255273729@critter.freebsd.dk>	<6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>	<20091012102721.GK20296@fysh.org>
	<A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
Message-ID: <4AD4A907.40809@comcast.net>

Steve Allen wrote "In the time scales for TAI, LORAN-C, GPS, and
now BST the word "day" already has a meaning more clearly
communicated by "atomic day".

Is BST British Summer Time? If so, is there some new statute in the
UK adopting time offset from UTC rather than offset from the ill-defined
GMT? (Of course the offset is 0 in the winter.)

Gerry Ashton
USA

From sla at ucolick.org  Tue Oct 13 12:29:01 2009
From: sla at ucolick.org (Steve Allen)
Date: Tue, 13 Oct 2009 09:29:01 -0700
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <4AD4A907.40809@comcast.net>
References: <7197.1255273729@critter.freebsd.dk>
	<6FEE3736-427A-44BC-8B8A-B6C00A7CCD88@ucolick.org>
	<20091012102721.GK20296@fysh.org>
	<A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
	<4AD4A907.40809@comcast.net>
Message-ID: <20091013162901.GD26416@ucolick.org>

On Tue 2009-10-13T12:21:27 -0400, ashtongj hath writ:
> Is BST British Summer Time? If so, is there some new statute in the
> UK adopting time offset from UTC rather than offset from the ill-defined
> GMT? (Of course the offset is 0 in the winter.)

BeiDou System Time, the time scale used by the Compass navigation
satellite system being flown by Peoples Republic of China.

BST was equal to UTC on 2006-01-01 and has no leap seconds.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    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  Tue Oct 13 13:33:22 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 13 Oct 2009 11:33:22 -0600 (MDT)
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <4AD4A907.40809@comcast.net>
References: <20091012102721.GK20296@fysh.org>
	<A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
	<4AD4A907.40809@comcast.net>
Message-ID: <20091013.113322.-687458600.imp@bsdimp.com>

In message: <4AD4A907.40809 at comcast.net>
            ashtongj <ashtongj at comcast.net> writes:
: Steve Allen wrote "In the time scales for TAI, LORAN-C, GPS, and
: now BST the word "day" already has a meaning more clearly
: communicated by "atomic day".
: 
: Is BST British Summer Time? If so, is there some new statute in the
: UK adopting time offset from UTC rather than offset from the ill-defined
: GMT? (Of course the offset is 0 in the winter.)

BST is the Chinese navigation satellite time base.  I forget what the
B stands for.

Warner

From imp at bsdimp.com  Tue Oct 13 13:39:11 2009
From: imp at bsdimp.com (M. Warner Losh)
Date: Tue, 13 Oct 2009 11:39:11 -0600 (MDT)
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <20091013162901.GD26416@ucolick.org>
References: <A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
	<4AD4A907.40809@comcast.net> <20091013162901.GD26416@ucolick.org>
Message-ID: <20091013.113911.-447291794.imp@bsdimp.com>

In message: <20091013162901.GD26416 at ucolick.org>
            Steve Allen <sla at ucolick.org> writes:
: On Tue 2009-10-13T12:21:27 -0400, ashtongj hath writ:
: > Is BST British Summer Time? If so, is there some new statute in the
: > UK adopting time offset from UTC rather than offset from the ill-defined
: > GMT? (Of course the offset is 0 in the winter.)
: 
: BeiDou System Time, the time scale used by the Compass navigation
: satellite system being flown by Peoples Republic of China.
: 
: BST was equal to UTC on 2006-01-01 and has no leap seconds.

Are all the other time scales supposed to be nominally TAI + offset +
error-in-execution-that-is-tiny, or are there some other subtle
definitions that makes them evolve in a way that's different than TAI?

Warner


From sla at ucolick.org  Tue Oct 13 17:36:27 2009
From: sla at ucolick.org (Steve Allen)
Date: Tue, 13 Oct 2009 14:36:27 -0700
Subject: [LEAPSECS] POSIX Time
In-Reply-To: <20091013.113911.-447291794.imp@bsdimp.com>
References: <A2979496-702F-40B1-A9E2-BD23AFDA38C9@ucolick.org>
	<4AD4A907.40809@comcast.net> <20091013162901.GD26416@ucolick.org>
	<20091013.113911.-447291794.imp@bsdimp.com>
Message-ID: <20091013213627.GG26416@ucolick.org>

On Tue 2009-10-13T11:39:11 -0600, M. Warner Losh hath writ:
> Are all the other time scales supposed to be nominally TAI + offset +
> error-in-execution-that-is-tiny, or are there some other subtle
> definitions that makes them evolve in a way that's different than TAI?

See Lewandowski at CGSIC 49
http://www.navcen.uscg.gov/CGSIC/meetings/49thmeeting/Reports/%5B39%5DTiming_WL_General.pdf

Especially see the ICG draft recommendation.  If that takes force then
BIPM's repeated alarms about "proliferation of time scales" may cease
to have basis (but as worded that is true only so long as UTC
continues to have something like its current relation to TAI).

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m

From dan at tobias.name  Tue Oct 13 20:09:55 2009
From: dan at tobias.name (Daniel R. Tobias)
Date: Tue, 13 Oct 2009 20:09:55 -0400
Subject: [LEAPSECS] POSIX Time (was WP7A)
In-Reply-To: <20091013162901.GD26416@ucolick.org>
References: <7197.1255273729@critter.freebsd.dk>, <4AD4A907.40809@comcast.net>,
	<20091013162901.GD26416@ucolick.org>
Message-ID: <4AD516D3.18053.6B4277C1@dan.tobias.name>

On 13 Oct 2009 at 9:29, Steve Allen wrote:

> BeiDou System Time, the time scale used by the Compass navigation
> satellite system being flown by Peoples Republic of China.
> 
> BST was equal to UTC on 2006-01-01 and has no leap seconds.

I don't know what the point is to creating yet another time scale 
that differs from TAI by yet another integral offset different from 
that of the other integral-offset time scales.  They couldn't use one 
equal to TAI or TT or GPS time?  In an ideal world, there'd be only 
two scales, one based on pure atomic time and one on Earth rotation 
(well, once other planets are settled, there'd be scales based on 
their rotation too).

And they had to use an ambiguous initialism for it, the same as 
British Summer Time, which has already confused one poster here.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/



From joegwinn at comcast.net  Sun Oct 18 16:52:55 2009
From: joegwinn at comcast.net (Joe Gwinn)
Date: Sun, 18 Oct 2009 16:52:55 -0400
Subject: [LEAPSECS] systems that use GPS time
In-Reply-To: <6300EA17-840B-46BB-B665-378F65B6289D@ucolick.org>
References: <6300EA17-840B-46BB-B665-378F65B6289D@ucolick.org>
Message-ID: <p0624080bc6f83b4c0f8a@[192.168.1.212]>

At 6:43 PM -0700 10/11/09, Steve Allen wrote:
>Are there any folks who can comment on the operation of ensembles
>of systems which use GPS time instead of UTC?

I can answer for systems I have worked on.


>What are these systems?

Many large ground-based radars and the like.


>What reasoning went into the choice of GPS time?

It's cheaper and far more reliable to generate a continuous timescale 
than to adapt millions of lines of code to handle time jumps. 
Trackers in particular don't like time jumps, and negative jumps are 
a particular problem.

Given that UTC cannot be used, what is the easiest alternative? 
Well, GPS Time is widely disseminated, as many commercially-available 
GPS receivers can be configured to provide it.

Naval systems I worked on in the days before GPS generated their own 
monotonic local timescales.  One common approach was to count 
milliseconds since the official birthday of Christ (0h 0m 0s 1 
January 0001 AD) in a 48-bit integer.  The Gregorian calendar was 
used in these calculations, even though it did not exist during 
Christ's life.  Synchronization to the outside world was by 
wristwatch.


>How did they reason so as to overcome the implicit mandates
>that POSIX and  international standards place on the use of UTC?
>Was the choice made because of an aversion to the handling of
>leap seconds, or were there other concerns?

If there is a requirement (often not the case), it's only a 
requirement on messages to and from the system, and not on how time 
is handled internally.

In systems where a one-second discontinuity would matter, there is a 
distinct aversion to leap seconds, because it's too hard to do enough 
tests to ensure that a leap second won't matter.


>Do they use the standard zoneinfo files and just tolerate the fact
>that the broken down time reports are off by a few seconds?
>Or do they install custom zoneinfo files and get reports as true
>UTC and/or local zone time?

None of the above.  Time zones are not used at all.  They use UTC 
directly or they use GPS Time directly.


Joe Gwinn

From lang at UNB.ca  Tue Oct 20 11:31:05 2009
From: lang at UNB.ca (Richard B. Langley)
Date: Tue, 20 Oct 2009 12:31:05 -0300
Subject: [LEAPSECS] At the centre of time
Message-ID: <1256052665.4addd7b9ab4f5@webmail.unb.ca>

At the centre of time

By Lucy Rodgers
BBC News

Without it international travel would be in turmoil and calling friends in faraway
places at the right time impossible. Exactly 125 years after the Greenwich Meridian
line was drawn, how and why did Britain become the centre of time?

<http://news.bbc.co.uk/2/hi/uk_news/magazine/8266883.stm>

===============================================================================
 Richard B. Langley                            E-mail: lang at unb.ca
 Geodetic Research Laboratory                  Web: http://www.unb.ca/GGE/
 Dept. of Geodesy and Geomatics Engineering    Phone:    +1 506 453-5142
 University of New Brunswick                   Fax:      +1 506 453-4943
 Fredericton, N.B., Canada  E3B 5A3
     Fredericton?  Where's that?  See: http://www.city.fredericton.nb.ca/
===============================================================================