[LEAPSECS] Future time

[Stephen Scott]

Most recent posts have tried to disect the past. This is about the use 
of time now and in the future.


_*UTC and Leap Seconds*_
The basis of my understanding is that UTC is a timescale that:
-progresses at a rate of the second (SI) and has done so since 
1972-01-01.
-is expressed as a count in the form of date, hours, minutes and 
seconds;
-is continuous other than the discontinuities resulting from leap 
second corrections;

-is currently the basis for most local timescales;
-is related to the International Atomic Timescale (TAI) by an 
integer leap second offset;
-until further notice, is in force and is not expected to be 
revised, at least not before 2015.

My primary interest is not how we got here but how we go into the future.

_*The growing importance of precise time*_
My background, experience and field of interest are primarily in 
timekeeping and signal generation for television production and 
broadcast. In a broad sense television also includes radio and 
distribution of other forms of media.


Precise time is important in television both for the synchronization of 
various program elements (for example audio/video lip-sync) and the 
quality-of-experience (QoE) to the viewer of program segments which must 
flow smoothly from one segment to the next.


Historically television developed as a system that was isochronous 
glass-to-glass. Typically, within a television facility time, and 
synchronization reference signals are generated at a central point and 
distributed within the plant in a star topology. These reference signals 
are generated from stable local oscillators and because discontinuities 
are disruptive to synchronous operations they are corrected to an 
external reference, at a time-of-day that will be the least disruptive. 
With the replacement of some synchronous signal technologies by packet 
switched signals there is a desire to replace or supplement traditional 
reference signal distribution with a system that is based on a global 
time reference that can be used to generate timing reference signals at 
the point of use. The diminished central control over the management of 
discontinuities in the time references places an increasing importance 
on the deterministic nature of these time references.


How much resolution and precision is required? The answer is not 
universal and depends on the application but for example:
-A leap second shift represents about 30 video frames in North 
America or 25 frames in Europe. Most television operations are based on 
single frame accuracy.
-Audio can require much higher accuracy when considering spatial 
rendition of multi-channel audio.
-Video signals are based on very precise frequencies. Recreating 
frequencies requires very accurate and deterministic timestamps.
A peculiarity of the North American television system is the actual 
frame rate is 30/1.001 Hz. This non-integer rate creates an additional 
complication to generating reference signals and an additional 
dependence on the time reference being deterministic. This may require 
microsecond accuracy and 24/7 availability.


_*Instantiation of leap seconds*_
In a prior inquiry about leap seconds I had asked about the application 
of leap seconds to various local tines in the different time zones. I 
have searched for documentation on how the leap seconds are instantiated 
in local time zones around the world. There is a need for a standard. 
This is a reiteration of the request for information.


This question was raised because TF.460-6 specifies the leap second 
adjustment to UTC and the emission of UTC. There does not seem to be any 
guidance for the application of leap seconds to local timescales for the 
timezones UTC+14 to UTC-12. There is the perception by some that the 
leap second should be instantiated globally at the same time as it is 
signaled by UTC. I looked in TF.460-6 but could not locate a definitive 
statement to this effect.


If this is the case then the leap second changes would be instantiated 
just before 9:00 (9 AM) local time in Tokyo (UTC+9) and just before 
19:00 (7 PM) local time in New York (UTC-5). These are just examples but 
in either case it would probably be disruptive to critical time keeping 
systems to have a time shift instantiated at these times. The 
broadcaster typically makes these changes at a time early in the 
morning. I cannot believe that any other industry that has a time 
critical operation does not do something similar.


It's not just for television. The evolving application of packet 
switched technologies (for example Ethernet and the Internet) in 
television, financial, scientific, telecommunications, power generation  
and other industries is creating a growing demand for the availability 
of accurate and precise, but most importantly deterministic time 
references. Several industries have developed IEEE 1588 PTP Profiles 
that address their specific needs.


Notwithstanding the possibili

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:

> Most recent posts have tried to disect the past. This is about the use of 
> time now and in the future.
> 
> UTC and Leap Seconds
> The basis of my understanding is that UTC is a timescale that:
> -progresses at a rate of the second (SI) and has done so since 1972-01-01.
> -is expressed as a count in the form of date, hours, minutes and seconds;
> -is continuous other than the discontinuities resulting from leap second 
> corrections;

To pick a pedantic nit: It is continuous. No "other than". UTC is a continuous 
time scale. It has a non-uniform radix that is expressed at the leap seconds 
when its rules for labeling seconds changes slightly to label the leap second 
23:59:60. The timescale has a discontinuity when there's a phase jump. UTC does 
not have phase jumps, even if it chooses a non-traditional time to label some 
of its seconds once every year and a half or two.

> -is currently the basis for most local timescales;

Most local timezones I don't believe they are actually timescales, in the 
technical sense.

> -is related to the International Atomic Timescale (TAI) by an integer 
> leap second offset;
> -until further notice, is in force and is not expected to be revised, at 
> least not before 2015.
...

> Instantiation of leap seconds
> In a prior inquiry about leap seconds I had asked about the application of 
> leap seconds to various local tines in the different time zones. I have 
> searched for documentation on how the leap seconds are instantiated in local 
> time zones around the world. There is a need for a standard. This is a 
> reiteration of the request for information.

The leap second is, by definition, inserted in the local time zone at the same 
instant that it is inserted into UTC.

> This question was raised because TF.460-6 specifies the leap second 
> adjustment to UTC and the emission of UTC. There does not seem to be any 
> guidance for the application of leap seconds to local timescales for the 
> timezones UTC+14 to UTC-12. There is the perception by some that the leap 
> second should be instantiated globally at the same time as it is signaled by 
> UTC. I looked in TF.460-6 but could not locate a definitive statement to this 
> effect.

Timezones are a matter for local government. However, since they are specified 
as being a fixed offset from UTC (or something that everybody fudges to be the 
same as UTC), this is the thing that mandates when the leap second is. In the 
horror show of the bizarre that's been paraded before this group, no examples 
have been presented where the leap is inserted at any time other than after 
23:59:59 UTC, even if that's in the middle of the localtime day.

> If this is the case then the leap second changes would be instantiated just 
> before 9:00 (9 AM) local time in Tokyo (UTC+9) and just before 19:00 (7 PM) 
> local time in New York (UTC-5). These are just examples but in either case it 
> would probably be disruptive to critical time keeping systems to have a time 
> shift instantiated at these times. The broadcaster typically makes these 
> changes at a time early in the morning. I cannot believe that any other 
> industry that has a time critical operation does not do something similar.

Leap seconds aren't disruptive to television broadcasts because they aren't 
required to be aligned to anything. Frequency is more important than what some 
standard labels the a particular second.

> It’s not just for television. The evolving application of packet switched 
> technologies (for example Ethernet and the Internet) in television, 
> financial, scientific, telecommunications, power generation  and other 
> industries is creating a growing demand for the availability of accurate and 
> precise, but most importantly deterministic time references. Several 
> industries have developed IEEE 1588 PTP Profiles that address their specific 
> needs.

PTP has no leap seconds.

> Notwithstanding the possibility of stopping leap seconds it is more important 
> to: 
> -have a deterministic procedure for instantiating leap seconds in each 
> time zone and;
> -similarly for standard time and daylight saving time shifts which 
> understandably are under local governance is lacking a   better method 
> for dissemination.

It happens when it happens in UTC universally on this planet.

> I believe there is no particular requirement to eliminate the leap second if 
> their insertions are well and deterministically defined and communicated. We 
> can’t fix what we don’t know. Similarly the need to define the standard time 
> / daylight saving time shifts, however that is beyond the scope of this group.

Leap seconds are evil and must die, leaving alignment to the sun to local 
governments. Others may have a contrary opinion.

> Summary
> Time implementations that have evolved over time are no longer good enough.

How exactly are they no longer "good enough?" The

Re: [LEAPSECS] Future time

[Clive D.W. Feather]

Stephen Scott said:
> The basis of my understanding is that UTC is a timescale that:
> -progresses at a rate of the second (SI) and has done so since 
> 1972-01-01.
> -is expressed as a count in the form of date, hours, minutes and 
> seconds;
> -is continuous other than the discontinuities resulting from leap 
> second corrections;

No.

It is continuous at all times. However, a UTC minute can be 59, 60, or 61
seconds long.

Thus at the end of June the UTC count may go:

--06-30 T 23:59:57
--06-30 T 23:59:58
--06-30 T 23:59:59
--07-01 T 00:00:00
--07-01 T 00:00:01
--07-01 T 00:00:02

or it may go:

--06-30 T 23:59:57
--06-30 T 23:59:58
--06-30 T 23:59:59
--06-30 T 23:59:60 (a positive leap second)
--07-01 T 00:00:00
--07-01 T 00:00:01
--07-01 T 00:00:02

or it may go:

--06-30 T 23:59:57
--06-30 T 23:59:58
--07-01 T 00:00:00 (a negative leap second)
--07-01 T 00:00:01
--07-01 T 00:00:02

(though the last of these has never happened yet).

> -is currently the basis for most local timescales;

Right, which is why changing its meaning is seen as the most efficient way
of changing lots of national times.

> With the replacement of some synchronous signal technologies by packet 
> switched signals there is a desire to replace or supplement traditional 
> reference signal distribution with a system that is based on a global 
> time reference that can be used to generate timing reference signals at 
> the point of use. The diminished central control over the management of 
> discontinuities in the time references places an increasing importance 
> on the deterministic nature of these time references.

There's no discontinuity in UTC itself. Thus it suffices for what you
require.

*HOWEVER*, if you represent the time as -MM-DD T hh:mm:ss *AND* don't
have a way of representing ss == 60, you have a problem. Similarly, if you
don't have an accurate list of leap seconds, you won't know whether the
time should go 58-59-00, 58-59-60-00, or 58-00. This latter is the
distribution problem.

> _*Instantiation of leap seconds*_
> In a prior inquiry about leap seconds I had asked about the application 
> of leap seconds to various local tines in the different time zones. I 
> have searched for documentation on how the leap seconds are instantiated 
> in local time zones around the world. There is a need for a standard. 
> This is a reiteration of the request for information.

The situation is clear.

(1) Leap seconds happen in UTC as shown above; that is, at the end of the
day.

(2) In countries where local time is defined as an offset from UTC, it
happens at the same *UTC* time. Thus if your local time is UTC+3:30, then
the sequence for a positive leap second is:

--07-01 T 03:29:58
--07-01 T 03:29:59
--07-01 T 03:29:60
--07-01 T 03:30:00
--07-01 T 03:30:01
--07-01 T 03:30:02

> This question was raised because TF.460-6 specifies the leap second 
> adjustment to UTC and the emission of UTC.

This is the statement that specifies (1).

> There does not seem to be any 
> guidance for the application of leap seconds to local timescales for the 
> timezones UTC+14 to UTC-12.

That's (2).

> There is the perception by some that the 
> leap second should be instantiated globally at the same time as it is 
> signaled by UTC. I looked in TF.460-6 but could not locate a definitive 
> statement to this effect.

It wouldn't be in TF.460-6. It would be in the definition of local time in
that time zone. If the time zone is defined as UTC+3:30, then *BY
DEFINITION* the leap second happens at 03:29:60 local time.

> If this is the case then the leap second changes would be instantiated 
> just before 9:00 (9 AM) local time in Tokyo (UTC+9) and just before 
> 19:00 (7 PM) local time in New York (UTC-5).

Correct. Though a June one would be 20:00 local time in New York.

And just before 05:30 in the morning in India, and at 09:30 or 10:30 in
South Australia.

> These are just examples but 
> in either case it would probably be disruptive to critical time keeping 
> systems to have a time shift instantiated at these times.

There is no shift, just variable base arithmetic.

But this is one of the reasons for abolishing leap seconds.

> It's not just for television. The evolving application of packet 
> switched technologies (for example Ethernet and the Internet) in 
> television, financial, scientific, telecommunications, power generation  
> and other industries is creating a growing demand for the availability 
> of accurate and precise, but most importantly deterministic time 
> references.

Something that is incompatible with the present arrangements for the
announcement of leap seconds.

> Notwithstanding the possibility of stopping leap seconds it is more 
> important to:
> -have a deterministic procedure for instantiating leap seconds in 
> each time zone and;

They already exist. The leap second happens at m

Re: [LEAPSECS] Future time

[Daode]

Warner Losh  wrote:
 |Leap seconds are evil and must die, leaving alignment to the \

You know, i shouldn't speak up here; but what i am missing as
a C++/C/ programmer is the possibility to actually know the true
context, and work with it.  I.e., clock_gettime(CLOCK_TAI) and
clock_gettime(CLOCK_UTC), as well as the utility functions which
know the kind of time they're working on.

Of course, if you expect the current timezone to be set properly
to a valid local time it is possible to apply all necessary
adjustments; i.e. via the Olson / IANA database as shown by [1],
_when_ the right/ directory is available on the system (not on
Snow Leopard by default), but that is not the same.

  [1] 

 |Leap seconds are evil and must die, leaving alignment to the \
 |sun to local governments. Others may have a contrary opinion.

I think the intellectual property that backs TAI and UTC is
a great cultural achievement.  A single global institute, IERS
[2], is responsible for adjusting the leap offset to compute TAI
from UTC based times.  Imho it is unacceptable to change "truth"
or "environmental reality" (as "we" believe to know it today) to
something ??

  [2]  / 

 |> -Promote standards for the communication of all UTC time \
 |> corrections including leap seconds and standard / daylight \
 |> saving time shifts.
 |
 |The de-facto standard here are the Olson databases...

So you are willing to drop the earth's reality in favour of many,
many new entries in the Olson DB, which still need to drift apart
from their real daylight, yet very slowly, and local and thus
invisible, to make the POSIX sentence "every day shall be
accounted for by exactly 86 400 seconds" true.
But i really don't know; POSIX says

  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

So what else but offering new interfaces to such judged
applications is possible?

  Those applications which do care about leap seconds can determine
  how to handle them in whatever way those applications feel is
  best.

I think today this would require including a leap second table
yourself.  I do know for sure that my gettimeofday() returns
a seconds-since-the-epoch that includes leap seconds, so, without
Olson right/, i'm afraid the timestamps are wrong.

--steffen
--- Begin Message ---

On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:

> Most recent posts have tried to disect the past. This is about the use of 
> time now and in the future.
> 
> UTC and Leap Seconds
> The basis of my understanding is that UTC is a timescale that:
> -progresses at a rate of the second (SI) and has done so since 1972-01-01.
> -is expressed as a count in the form of date, hours, minutes and seconds;
> -is continuous other than the discontinuities resulting from leap second 
> corrections;

To pick a pedantic nit: It is continuous. No "other than". UTC is a continuous 
time scale. It has a non-uniform radix that is expressed at the leap seconds 
when its rules for labeling seconds changes slightly to label the leap second 
23:59:60. The timescale has a discontinuity when there's a phase jump. UTC does 
not have phase jumps, even if it chooses a non-traditional time to label some 
of its seconds once every year and a half or two.

> -is currently the basis for most local timescales;

Most local timezones I don't believe they are actually timescales, in the 
technical sense.

> -is related to the International Atomic Timescale (TAI) by an integer 
> leap second offset;
> -until further notice, is in force and is not expected to be revised, at 
> least not before 2015.
...

> Instantiation of leap seconds
> In a prior inquiry about leap seconds I had asked about the application of 
> leap seconds to various local tines in the different time zones. I have 
> searched for documentation on how the leap seconds are instantiated in local 
> time zones around the world. There is a need for a standard. This is a 
> reiteration of the request for information.

The leap second is, by definition, inserted in the local time zone at the same 
instant that it is inserted into UTC.

> This question was raised because TF.460-6 specifies the leap second 
> adjustment to UTC and the emission of UTC. There does not seem to be any 
> guidance for the application of leap seconds to local timescales for the 
> timezones UTC+14 to UTC-12. There is the perception by some that the leap 
> second should be instantiated globally at the same time as it is signaled by 
> UTC. I looked in TF.460-6 but could not locate a definitive statement to this 
> effect.

Timezones are a matter for local government. However, since they are specified 
as being a fixed offset from UTC (or

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
> 
>  Those applications which do care about leap seconds can determine
>  how to handle them in whatever way those applications feel is
>  best.

The problem is that all applications should care about leap seconds. It is a 
part of the time standard (UTC) that is papered over in POSIX time_t. This is a 
false partitioning, and what causes the probelms.

> I think today this would require including a leap second table
> yourself.  I do know for sure that my gettimeofday() returns
> a seconds-since-the-epoch that includes leap seconds, so, without
> Olson right/, i'm afraid the timestamps are wrong.

This turns out to be difficult to arrange if you have to know time early in 
your startup sequence. GPS receivers can give it to you, unless they are a 
'cold spare' that have been turned off for more than 6 months, then you have a 
time jump if there's been a leap second in the interim (because cached values 
become wrong)...  Or you have a delay until the number is known after the 
almanac is downloaded. It is this problem that's lead me and others to suggest 
a longer time horizon for leap seconds to ensure that the use cases are more 
easily handled.

Of course, the 6 month window does make it impossible to compute a time_t for a 
known interval into the future that's longer than 6 months away...

Warner

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Tom Van Baak]

> The problem is that all applications should care about leap seconds.
> It is a part of the time standard (UTC) that is papered over in POSIX time_t.
> This is a false partitioning, and what causes the probelms.

Warner,

"All" applications should care? It's that going a bit too far? What, are you 
going to ban every analog clock? Fahrenheit 86400?

UTC is simple and clearly defined and we all know the ideal/right way to handle 
that time scale, and by arithmetic offset, any local time. But there is also 
the matter of precision: different applications are looking for different 
levels of UTC precision. The often unstated precision requirement makes a big 
difference.

Where you get UTC from and how you store or display UTC are dependent on the 
type of application. Applications needing 1 ns precision must use a UTC(k) with 
circular-T, UTCr, or other real-time or post processing corrections applied. 
Applications needing only 1 us or 100 ns precision can get UTC via cheap GPS 
receivers. Applications needing 1 ms precision can use NTP. Those that need 
only 2 s or worse precision can get away with ignoring leap seconds, if they 
choose, because the resulting time-stamps are still well within the 
specification.

/tvb


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Daniel R. Tobias]

On 18 Jan 2014 at 19:51, Warner Losh wrote:

> Of course, the 6 month window does make it impossible to compute a time_t for 
> a known
> interval into the future that's longer than 6 months away...

What are the applications that actually need to schedule events more 
than 6 months in the future that need to be precisely synchronized to 
civil time at a resolution of under a second? Gee, I might miss the 
plane for the airline reservation I made 7 months in advance if I 
show up one second late! (Actually, both myself and the airline, if 
we care about this level of detail, will have adjusted our 
clocks/watches by flight day, including any leap seconds in the 
interim, and I'll be right on time.)

-- 
== 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/


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Gerard Ashton]

Date/time manipulation software sometimes converts a date expressed as day,
month, year, time to a number, as in Excel. If the number counts leap
seconds, and an event is more than 6 months in the future, it will be
necessary to search for the number using a range rather than an exact
number. For example, if Excel were revised to account for leap seconds, and
one wanted to search for 8 PM January 14, 2015, rather than searching for
42018.8333... one would have to search for something like a time t, where
42018.83332 < t < 42018.83335. This of course overlooks whatever "fuzz"
Excel may silently employ in searches.

Gerard Ashton

-Original Message-
From: leapsecs-boun...@leapsecond.com
[mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Daniel R. Tobias
Sent: Sunday, January 19, 2014 10:35 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Future time

On 18 Jan 2014 at 19:51, Warner Losh wrote:

> Of course, the 6 month window does make it impossible to compute a 
> time_t for a known interval into the future that's longer than 6 months
away...

What are the applications that actually need to schedule events more than 6
months in the future that need to be precisely synchronized to civil time at
a resolution of under a second? Gee, I might miss the plane for the airline
reservation I made 7 months in advance if I show up one second late!
(Actually, both myself and the airline, if we care about this level of
detail, will have adjusted our clocks/watches by flight day, including any
leap seconds in the interim, and I'll be right on time.)

--
== 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/


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 18, 2014, at 10:16 PM, Tom Van Baak wrote:

>> The problem is that all applications should care about leap seconds.
>> It is a part of the time standard (UTC) that is papered over in POSIX time_t.
>> This is a false partitioning, and what causes the probelms.
> 
> Warner,
> 
> "All" applications should care? It's that going a bit too far? What, are you 
> going to ban every analog clock? Fahrenheit 86400?

All applications should care. Otherwise, it isn't a universal time standard and 
becomes a non-standard footnote. All applications should get leap seconds 
right, even if they delegate that to a library that handles the details.

> UTC is simple and clearly defined and we all know the ideal/right way to 
> handle that time scale, and by arithmetic offset, any local time. But there 
> is also the matter of precision: different applications are looking for 
> different levels of UTC precision. The often unstated precision requirement 
> makes a big difference.

All applications should be able to cope with leap seconds when present, or when 
absent.

> Where you get UTC from and how you store or display UTC are dependent on the 
> type of application. Applications needing 1 ns precision must use a UTC(k) 
> with circular-T, UTCr, or other real-time or post processing corrections 
> applied. Applications needing only 1 us or 100 ns precision can get UTC via 
> cheap GPS receivers. Applications needing 1 ms precision can use NTP. Those 
> that need only 2 s or worse precision can get away with ignoring leap 
> seconds, if they choose, because the resulting time-stamps are still well 
> within the specification.

"get away with" is part of the problem. It means UTC truly isn't universally 
adapted. It needs to be, or leap seconds will continue to be a thorn in the 
side of things. Applications "ignore" them because they are hard or require 
extra effort. They don't ignore them because they don't want them and are 
rejecting leap seconds. They ignore them because they want to hit the easy 
button. My point is that they should be able to ignore these details of leap 
seconds much like they ignore dates and such. There's good libraries and APIs 
that make it possible to pretty much ignore all the details about dates and 
knowing that March has 30 days. No such libraries are in wide spread use, and 
time_t militates against its creation in many ways.

That's what I mean by "all" applications (computer applications) should care. 
Otherwise we get the two-tier system we have now where leap seconds are such 
second class citizens applications wanting to get them right have to jump 
through lots of hoops (doing their own time stuff), or they have to sacrifice 
some aspect of time to make things work: Give up on monotonically increasing 
time_t, give up on actually doing leap seconds (by smearing ala Google), etc.

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 8:34 AM, Daniel R. Tobias wrote:

> On 18 Jan 2014 at 19:51, Warner Losh wrote:
> 
>> Of course, the 6 month window does make it impossible to compute a time_t 
>> for a known
>> interval into the future that's longer than 6 months away...
> 
> What are the applications that actually need to schedule events more 
> than 6 months in the future that need to be precisely synchronized to 
> civil time at a resolution of under a second? Gee, I might miss the 
> plane for the airline reservation I made 7 months in advance if I 
> show up one second late! (Actually, both myself and the airline, if 
> we care about this level of detail, will have adjusted our 
> clocks/watches by flight day, including any leap seconds in the 
> interim, and I'll be right on time.)

It is this kind of scorn and derision that makes it hard to actually come up 
with a solution. Sometimes you don't find out about leap seconds that far in 
advance. The key is that having leap seconds not known makes computation of 
future times as a count of seconds impossible. It might not matter "much" but 
the not caring about all the details has contributed to very few things 
actually getting leap seconds right. It is just a second, right?

Warner


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Steve Allen]

On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
> That's what I mean by "all" applications (computer applications)
> should care.  Otherwise we get the two-tier system we have now where
> leap seconds are such second class citizens applications wanting to
> get them right have to jump through lots of hoops (doing their own
> time stuff), or they have to sacrifice some aspect of time to make
> things work: Give up on monotonically increasing time_t, give up on
> actually doing leap seconds (by smearing ala Google), etc.

Do all applications have to care and have consistent implementation
=> of the night shifts which are 7 hours long in spring and 9 in fall?
=> of the change to daylight time that Russia is rumored to be
   considering to decree after Sochi is over?
=> of the sequence of calendar days in Samoa when it moved itself
   across the International Date Line?n

All applications on Mac/iPhone/iPad in Jordan right now that care
about the time zone are getting it wrong by an hour.  Life in Jordan
goes on.

If the leap seconds were placed into a similarly inconsequential part
of the interfaces then the applications could be similarly wrong about
leap seconds yet life would go on.

--
Steve Allen WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Poul-Henning Kamp]

In message <20140119164807.ga19...@ucolick.org>, Steve Allen writes:

>If the leap seconds were placed into a similarly inconsequential part
>of the interfaces then the applications could be similarly wrong about
>leap seconds yet life would go on.

They are.  It does.  So far.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 9:48 AM, Steve Allen wrote:

> On Sun 2014-01-19T09:20:31 -0700, Warner Losh hath writ:
>> That's what I mean by "all" applications (computer applications)
>> should care.  Otherwise we get the two-tier system we have now where
>> leap seconds are such second class citizens applications wanting to
>> get them right have to jump through lots of hoops (doing their own
>> time stuff), or they have to sacrifice some aspect of time to make
>> things work: Give up on monotonically increasing time_t, give up on
>> actually doing leap seconds (by smearing ala Google), etc.
> 
> Do all applications have to care and have consistent implementation
> => of the night shifts which are 7 hours long in spring and 9 in fall?
> => of the change to daylight time that Russia is rumored to be
>   considering to decree after Sochi is over?
> => of the sequence of calendar days in Samoa when it moved itself
>   across the International Date Line?n

They do care, because they use the olson database and that just takes care of 
it.

> All applications on Mac/iPhone/iPad in Jordan right now that care
> about the time zone are getting it wrong by an hour.  Life in Jordan
> goes on.

The olson database updates will take care of that.

> If the leap seconds were placed into a similarly inconsequential part
> of the interfaces then the applications could be similarly wrong about
> leap seconds yet life would go on.

Correct. That's my point. Nearly all programs use the olson database through 
libc, and get time as right as they can. Leap seconds aren't in a similar 
position (despite being in the olson database, they are effectively unused). My 
point is that this should change, or leap seconds will continue to be a thorn 
in the side of everybody. It is broken by design...

Warner

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[John Hawkinson]

Daniel R. Tobias  wrote on Sun, 19 Jan 2014
at 10:34:41 -0500 in <52dbf091.26529.1101b...@dan.tobias.name>:


> What are the applications that actually need to schedule events more 
> than 6 months in the future that need to be precisely synchronized to 
> civil time at a resolution of under a second? Gee, I might miss the 
> plane for the airline reservation I made 7 months in advance if I 

It is not so simple.

Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
August 1, 2014.

Then a leap second happens.

If my calendar software changes my event to start at 2:59:59pm 
instead, it may annoy users. "I put this in for 3pm, it shouldn't
be telling me 2:59:59! I don't like this program." (Or worse,
like displaying it at 2:59pm; or not showing it in a graphical
view because the constraint is "all events starting on or after 3pm.")

It's not so easy to decide what the appropriate precision necessarily
is for user interactions. It's...tricky.

--jh...@mit.edu
  John Hawkinson
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Stephen Colebourne]

On 19 January 2014 15:34, Daniel R. Tobias  wrote:
> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>
>> Of course, the 6 month window does make it impossible to compute a time_t 
>> for a known
>> interval into the future that's longer than 6 months away...
>
> What are the applications that actually need to schedule events more
> than 6 months in the future that need to be precisely synchronized to
> civil time at a resolution of under a second? Gee, I might miss the
> plane for the airline reservation I made 7 months in advance if I
> show up one second late! (Actually, both myself and the airline, if
> we care about this level of detail, will have adjusted our
> clocks/watches by flight day, including any leap seconds in the
> interim, and I'll be right on time.)

If you want to store a time in the future its best to focus on the
local time. In API terms, a UTC class is best representing data using
two numbers, typically modified-julian-day + second-of-day. Stored
like that, the announcement of a leap second doesn't generally affect
things. ie. Separation of the concept of day/date from time-of-day is
a Good Thing for most users.

When such concepts were in Java's JSR-310, I concluded that you needed
to have both TAI and UTC to provide full user control. TAI so a user
could schedule something n SI seconds in the future and UTC to
schedule something more sensibly. Eventually we concluded that most
users just don't care/know enough about TAI/UTC/leaps, so we removed
them.

Stephen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:

> On 19 January 2014 15:34, Daniel R. Tobias  wrote:
>> On 18 Jan 2014 at 19:51, Warner Losh wrote:
>> 
>>> Of course, the 6 month window does make it impossible to compute a time_t 
>>> for a known
>>> interval into the future that's longer than 6 months away...
>> 
>> What are the applications that actually need to schedule events more
>> than 6 months in the future that need to be precisely synchronized to
>> civil time at a resolution of under a second? Gee, I might miss the
>> plane for the airline reservation I made 7 months in advance if I
>> show up one second late! (Actually, both myself and the airline, if
>> we care about this level of detail, will have adjusted our
>> clocks/watches by flight day, including any leap seconds in the
>> interim, and I'll be right on time.)
> 
> If you want to store a time in the future its best to focus on the
> local time. In API terms, a UTC class is best representing data using
> two numbers, typically modified-julian-day + second-of-day. Stored
> like that, the announcement of a leap second doesn't generally affect
> things. ie. Separation of the concept of day/date from time-of-day is
> a Good Thing for most users.
> 
> When such concepts were in Java's JSR-310, I concluded that you needed
> to have both TAI and UTC to provide full user control. TAI so a user
> could schedule something n SI seconds in the future and UTC to
> schedule something more sensibly. Eventually we concluded that most
> users just don't care/know enough about TAI/UTC/leaps, so we removed
> them.

You had me all the way until the last sentence...  s/removed/hid for power 
users/ would have been much better outcome. But I do understand that it seems 
to be part of the prevailing attitudes today...

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Daniel R. Tobias]

On 19 Jan 2014 at 11:07, Gerard Ashton wrote:

> Date/time manipulation software sometimes converts a date expressed as day,
> month, year, time to a number, as in Excel. If the number counts leap
> seconds, and an event is more than 6 months in the future, it will be
> necessary to search for the number using a range rather than an exact
> number. 

Date/time software can be problematic in a number of ways in dealing 
with future appointments (and past events) that are anchored in local 
civil time. When it attempts to convert it to some internal numerical 
representation at entry time, this is often based on things in effect 
with respect to the time and place of entry, and wind up in the wrong 
time when, between the entry time and the event time, there's a shift 
such as daylight-saving or moving to a different time zone. It can be 
really tricky, for instance, to enter events to take place in a 
different city you're going to travel to, or in a season when the DST 
time shift is different from the present, without it getting 
"auto-adjusted" in an incorrect manner. Importing out-of-town 
convention schedules into an iPhone can be hit-and-miss depending on 
how time zones are coded in the file you're importing.

Not to mention what happens if, as has happened in lots of times and 
places, the government suddenly changes the time zone boundaries or 
DST rules, causing some future appointment to shift again.

When I'm making an advance dinner reservation for 7 PM on October 1, 
2014 in New York City, I expect that the time of this event will be 
fixed to the civil time in effect in that city on that date, possibly 
subject to arbitrary governmental fiat between now and then so that I 
can never be sure precisely what atomic-clock point that will refer 
to. Thus, I'd like any electronic storage of this appointment to be 
in terms of local civil time, so it makes the shifts correctly if its 
standard changes (including any intervening leap seconds, as well as 
other adjustments that might be much larger such as 1-hour shifts). 
Now, if the reservation happens to be at 2:30 AM on the night that 
daylight saving time springs forward, then I'm in trouble, which is 
why such shifts tend to be scheduled in the wee hours.

If, on the other hand, I want a precise interval in atomic seconds, 
such as to time an athletic competition or scientific experiment, 
then a stopwatch or countdown/count-up timer would be what I needed, 
with no necessary connection to civil time.

-- 
== 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/


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Brooks Harris]

On 2014-01-19 08:07 AM, Gerard Ashton wrote:

Date/time manipulation software sometimes converts a date expressed as day,
month, year, time to a number, as in Excel. If the number counts leap
seconds, and an event is more than 6 months in the future, it will be
necessary to search for the number using a range rather than an exact
number. For example, if Excel were revised to account for leap seconds, and
one wanted to search for 8 PM January 14, 2015, rather than searching for
42018.8333... one would have to search for something like a time t, where
42018.83332 < t < 42018.83335. This of course overlooks whatever "fuzz"
Excel may silently employ in searches.

Use extreme caution with Excel - for examples -

http://support.microsoft.com/kb/214094

http://www.mathworks.com/help/matlab/import_export/when-to-convert-dates-from-excel-files.html

http://answers.oreilly.com/topic/1700-how-to-calculate-the-difference-between-dates-in-excel-using-datedif/

Also be very careful with calculations - its floating point.



Gerard Ashton

-Original Message-
From: leapsecs-boun...@leapsecond.com
[mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Daniel R. Tobias
Sent: Sunday, January 19, 2014 10:35 AM
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Future time

On 18 Jan 2014 at 19:51, Warner Losh wrote:


Of course, the 6 month window does make it impossible to compute a
time_t for a known interval into the future that's longer than 6 months

away...

What are the applications that actually need to schedule events more than 6
months in the future that need to be precisely synchronized to civil time at
a resolution of under a second? Gee, I might miss the plane for the airline
reservation I made 7 months in advance if I show up one second late!
(Actually, both myself and the airline, if we care about this level of
detail, will have adjusted our clocks/watches by flight day, including any
leap seconds in the interim, and I'll be right on time.)

--
== 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/


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Joseph Gwinn]

On Sat, 18 Jan 2014 19:51:33 -0700, Warner Losh wrote:
> 
> On Jan 18, 2014, at 5:21 PM, Steffen (Daode) Nurpmeso wrote:
>> 
>>  Those applications which do care about leap seconds can determine
>>  how to handle them in whatever way those applications feel is
>>  best.
> 
> The problem is that all applications should care about leap seconds. 
> It is a part of the time standard (UTC) that is papered over in POSIX 
> time_t. This is a false partitioning, and what causes the probelms.

There are applications where the timescale cannot have any step 
discontinuities.  Like airplane and missile guidance.

 
>> I think today this would require including a leap second table
>> yourself.  I do know for sure that my gettimeofday() returns
>> a seconds-since-the-epoch that includes leap seconds, so, without
>> Olson right/, i'm afraid the timestamps are wrong.
> 
> This turns out to be difficult to arrange if you have to know time 
> early in your startup sequence. GPS receivers can give it to you, 
> unless they are a 'cold spare' that have been turned off for more 
> than 6 months, then you have a time jump if there's been a leap 
> second in the interim (because cached values become wrong)...  Or you 
> have a delay until the number is known after the almanac is 
> downloaded. It is this problem that's lead me and others to suggest a 
> longer time horizon for leap seconds to ensure that the use cases are 
> more easily handled.
> 
> Of course, the 6 month window does make it impossible to compute a 
> time_t for a known interval into the future that's longer than 6 
> months away...

And there is always the problem that one really really hopes that the 
guidance still works after an unpredicted leap.

So, one creates a TAI-like timescale.  This also simplifies the 
software, as only a few human-facing applications need to care about 
leap seconds, and if these few applications stumble, it's only an 
annoyance.

Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Poul-Henning Kamp]

In message <52dc19ff.9499.11a39...@dan.tobias.name>, "Daniel R. Tobias" writes:

>When I'm making an advance dinner reservation for 7 PM on October 1, 
>2014 in New York City, I expect that [...]

That used to be the "sensible party position", but it breaks down
in heaps once you start to schedule tele-conferences etc.

Does "Telecon, New York, 3pm Oct 1" mean that is when it will
actually happen in New York, or does it mean that it will happen
at "11:00Z" and somebody tried to translate that to New York time
and got it wrong or didn't know about US' DST rules or .. ?

In the end, only the user can know what the timestamp *really*
means, and if it is not communicated with sufficient specificity,
things go poorly.

I make a point out of scheduling anything involving remote participants
on the UTC timescale, leaving up to them to figure out when to get
out of bed in their local realities.

My experience is that people react with surprise initially, but
that once you've "broken them in" and explained why you do it, there
are far fewer "oops I missed the time" incidents, in particular
around DST changes.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Michael Spacefalcon]

John Hawkinson  wrote:

> Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
> August 1, 2014.
>
> Then a leap second happens.
>
> If my calendar software changes my event to start at 2:59:59pm 

Scenarios like the above are precisely the reason why I, Markus Kuhn
and Google Leap Smear users have been telling you all along that is
wrong to use Newtonian/Einsteinian time when the real need is for
*civil* time instead.

We need two entirely separate and mostly-disconnected (see below)
forms of time: N/E interval time on one hand, and "rubbery" civil time
on the other hand.

The problem is in the minds of people like PHK and Warner Losh.  Every
time we (me, Markus Kuhn and others of similar mind) advocate for a
"rubbery" civil time scale with "rubber seconds", we get shot down
with cries of how one can't use rubber time for air traffic control,
etc.  So what you, the "anti-rubber" crowd, are effectively saying is
that "rubbery" civil time is not an acceptable substitute for uniform
interval time.

But we assert the converse as well: uniform interval time is not an
acceptable substitute for rubbery civil time either, at least for
those of us who (for whatever legal, moral, philosophical, religious
or purely personal reasons) wish to retain Earth's rotation as the
fundamental basis of *our* civil time.

If inviduals like PHK and Warner Losh were stripped of their ill-gotten
power to dictate to the rest of the software world their edict of "thou
shalt use uniform interval time whether it's the appropriate timescale
for you or not", then all "leap second problems" would instantly go
away: *civil* time (as opposed to real time) applications would switch
to using something like UTC-SLS or UTR (the former is contingent of
UTC retaining its current leap seconds, but the latter is a variant
without such requirement), whose "second" counts are NOT SI seconds,
but merely measures of the angle by which the hands of an official
civil time clock are turning, and all simple date-time math will work
without burdening all of us with keeping track of leap seconds.

Back to my point about uniform interval time and "rubbery" civil time
being "mostly-disconnected": what I have in mind is a system like
house electrical wiring with separate "ground" and "neutral" wires.
At least here in USA, the electrical codes stipulate that the two be
connected at one common point, but are then wired separately from that
point onward.  "Rubbery" civil time would be algorithmically derived
from uniform interval time (atomic time), via a very simple linear
formula like Markus Kuhn's UTC-SLS (my proposed UTR is essentially the
same thing, but defined in a way that permits it to continue being
maintained independently if UTC-as-we-know-it goes away), and ideally
this algorithmic derivation of "rubbery civil time" from atomic time
would be done at an authoritative source such as a national time lab -
corresponding to the bonding point of "ground" and "neutral" wires in
my electrical analogy.

Continuing the electrical analogy, once a national time lab (it may
have to be the national time lab of a small micronation like Sealand
if no larger nation has the guts to step forward) has produced both
forms of time (pure atomic time and a rubberized civil time, related
by a known formula), both should be disseminated in parallel: for
example, on different UDP port numbers of an NTP-like Internet time
server.  All users would then have ready access to both forms of time,
but unlike in PHK-nian/Warner-Losh-ian world, no person, system or
application would be involuntarily forced to use or care about a form
of time they don't need.  An application that needs interval time only
(some "deeply embedded" technical system with no user interface at all
which doesn't need to know or care what day or time it is in the human
world) will be able to completely ignore the existence of the rubbery
civil time, whereas an application that needs civil time only, like
the OP's Excel example, would only look at the rubber second count and
ignore the SI second count.

Sure, there will be plenty of applications which need both, but once
again, no problem.  Air traffic control is a perfect example: use
interval time internally for everything, but when displaying flight
arrival and departure times for waiting passengers, convert them to
the "rubbery" civil time for display, using the known formula and the
widely-disseminated data table driving the rubberizations.

VLR,
SF
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 1:58 PM, Michael Spacefalcon wrote:

> John Hawkinson  wrote:
> 
>> Suppose a user enters an event in my calendar for 3:00pm US/Eastern on
>> August 1, 2014.
>> 
>> Then a leap second happens.
>> 
>> If my calendar software changes my event to start at 2:59:59pm 
> 
> Scenarios like the above are precisely the reason why I, Markus Kuhn
> and Google Leap Smear users have been telling you all along that is
> wrong to use Newtonian/Einsteinian time when the real need is for
> *civil* time instead.

First, you give me too much credit for power...

Second, you are breaking one of the aspects of time that is important for some 
application (you introduce a frequency error). This is no different than 
repeating a second or other measures that break time, only in your problem 
domain fewer things break. It papers over the problem in some ways, but causes 
problems for others, for which you propose "just use a different time scale."

But multiple time scales generally ends badly, or you eventually need to know 
the total number of leap seconds to translate from your special time scale to 
UTC. Having been there and done that it doesn't end well...

So I'm happy that you found a solution for your problems, but don't be so blind 
to think that it is an acceptable solution to all problems.

Warner

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Michael Spacefalcon]

Warner Losh  wrote:

> Second, you are breaking one of the aspects of time

Wrong - I simply assert other people's right to define the word "time"
in a different way than you do.  There exist perfectly valid definitions
of the word "time" which are distinct from "interval time", and which
are not broken in any slightest way by my approach.

> that is important for some application (you introduce a frequency error).

No, I do not introduce any "frequency error" - I can't, because the
term "frequency" has no defined meaning for the entity called "civil
time".  Instead, *you* introduce that error when and if you *misuse*
what I provide as "civil time" as if it were "interval time", ignoring
the product label that reads "don't do that".

You are seeking to suppress Earth-based civil time because some people
have misused and continue to misuse it in applications for which it is
not appropriate.  Are you also going to ban gasoline, because some
people misuse it for the purpose of committing arson, even though the
instructions on the gas pumps clearly say "for use as motor fuel only"?

> This is no different than repeating a second

There is one fundamental difference which you ignore: the mapping
between UTR (equivalent to UTC-SLS or Google's leap smear) and TAI
timestamps is 1-to-1, invertible, and precisely defined, when both are
treated as real numbers of conceptually infinite precision.

The reason why this bijective mapping is such a big deal is because
(if people on your side of the fence were willing to open their eyes a
little, that is) it would allow your precision real-time applications
to work properly.  Your whole beef with leap seconds seems to revolve
around the notion that you have applications for which uniform "atomic"
time is very important, which *also* need to interface with civil time
(otherwise you could just use something like GPS time and ignore UTC
altogether), and where no errors at all are tolerable, i.e., every
timestamp must be exactly precise, no fudge factor whatsoever.

Well, guess what, my system would allow you to have your cake and eat
it, if you would only look at it with an open mind instead of shooting
it down with prejudice!  The *only* work required on your part would
be to exercise a little care when defining your data structures: any
place where you have a timestamp of any kind, be clear on whether it
is a TAI-style one or a civil time one.  Different data types would
help: time_t is already well-established as the civil time data type,
so use/invent a new one for TAI-style timestamps, like that realtime_t
proposed by your buddy PHK on this list a couple of years ago.

Any time you need to convert from one to the other, call a library
function: the conversion is precisely defined and invertible.  Run
your internal clock on "atomic" time, and synthesize the "rubbery"
civil time inside your system per the standard defined formula and the
official Earth Corrections data table that goes with it.  Problem
solved!

> But multiple time scales generally ends badly,

Not necessarily - you still have not provided any valid objection to
my design in which the "rubbery" time scale is algorithmically derived
from the "atomic" one, and in which one can convert timestamps back
and forth in an invertible manner.

> or you eventually need to know the total number of leap seconds to translate
> from your special time scale to UTC.

Did you perhaps mean "to translate from UTR/UTC-SLS/LeapSmear to a
TAI-like timescale"?  Translating from a rubbery Earth-following
timescale to UTC as the latter is currently defined requires no
knowledge of the historical leap seconds.

But yes, of course a high-precision "both real-time and civil"
application of the kind you are presumably concerned with will need to
be fed with up-to-date information regarding upcoming Earth Corrections,
and to remember all historical ones.  But where is the problem with
that?  Just define a standard data format, a standard protocol for
transferring the updates, and a standard way of locating the authoritative
servers - yes, will take some work, but certainly very doable.  No more
difficult than DNS.

> So I'm happy that you found a solution for your problems,

No, neither I nor anyone else in my shoes has yet found any solution
to our biggest problem: namely, the threat that the familiar and
working Earth-following UTC which we currently rely on as an acceptable
realization of GMT will be forcibly taken away from us.

If your camp has your way in the ITU next year, who is going to pay
the cost of building a replacement for the lost UTC for those who
require a good faith realization of GMT?  What I need is an apparatus,
such as a special-purpose Stratum 1 NTP server that serves out UTR
instead of UTC, and which I can use to set the system time on all
computer systems under my care.  I will also need an easy way for my
family members and friends to switch all of their time-keeping devices
(computers, smartphones etc) from UT

Re: [LEAPSECS] Future time

[Tony Finch]

Poul-Henning Kamp  wrote:
> In message <52dc19ff.9499.11a39...@dan.tobias.name>, "Daniel R. Tobias" 
> writes:
>
> >When I'm making an advance dinner reservation for 7 PM on October 1,
> >2014 in New York City, I expect that [...]
>
> That used to be the "sensible party position", but it breaks down
> in heaps once you start to schedule tele-conferences etc.

In theory it works fine, if it is done properly. The organiser needs to
pick a primary location, where the local time of the appointment remains
fixed. There might be some secondary locations if some participants are
elsewhere; these are useful for automatically displaying the correct time
of the appointment for each person, and for the organiser to spot if their
proposed time happens to be 04:00 for one of the participants. The
secodary locations are also useful when a TZ rule change occurs: the
scheduler can find all the appointments that are affected by the rule
change, that is, appointments that occur in multiple locations where the
TZ rule change affects the locations differently. This kind of automated
assistance is impossible if you schedule in UTC.

If you schedule in a fixed zone (whether fixed UTC offset, or fixed local
time rules, or fixed Olson tz name) there are situations where a rule
change will invalidate your scheduling. However current scheduling
software requires you to schedule in this broken way because the main
calendaring data format (iCalendar) has the wrong data model. So in
practice it is impossible to schedule things in a way that is robust
against TZ changes.

There are other problems with existing calendaring software such as
getting time zone names wrong, e.g. implying the time zone in Lisbon in
the summer is called GMT.

So in practice scheduling in UTC makes sense.

Longer version of this argument: http://fanf.livejournal.com/104586.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Tony Finch]

Warner Losh  wrote:
> On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:

> > The basis of my understanding is that UTC is a timescale that:
> > -progresses at a rate of the second (SI) and has done so since 
> > 1972-01-01.
> > -is expressed as a count in the form of date, hours, minutes and 
> > seconds;
> > -is continuous other than the discontinuities resulting from leap 
> > second corrections;
>
> To pick a pedantic nit: It is continuous. No "other than". UTC is a
> continuous time scale. It has a non-uniform radix that is expressed at
> the leap seconds when its rules for labeling seconds changes slightly to
> label the leap second 23:59:60. The timescale has a discontinuity when
> there's a phase jump. UTC does not have phase jumps, even if it chooses
> a non-traditional time to label some of its seconds once every year and
> a half or two.

I think it is reasonable to say that UTC's labelling of seconds is
discontinuous. For timescales that use simple ancient sexagesimal notation
you can write down some straightforward formulae mapping between a count
of seconds and a broken down time. If you try to do the same for UTC you
have to write down something that is piecewise linear with exceptions. It
isn't a continuous map like other timescales.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Warner Losh]

On Jan 20, 2014, at 10:27 AM, Tony Finch wrote:

> Warner Losh  wrote:
>> On Jan 18, 2014, at 1:52 PM, Stephen Scott wrote:
> 
>>> The basis of my understanding is that UTC is a timescale that:
>>> -progresses at a rate of the second (SI) and has done so since 
>>> 1972-01-01.
>>> -is expressed as a count in the form of date, hours, minutes and 
>>> seconds;
>>> -is continuous other than the discontinuities resulting from leap 
>>> second corrections;
>> 
>> To pick a pedantic nit: It is continuous. No "other than". UTC is a
>> continuous time scale. It has a non-uniform radix that is expressed at
>> the leap seconds when its rules for labeling seconds changes slightly to
>> label the leap second 23:59:60. The timescale has a discontinuity when
>> there's a phase jump. UTC does not have phase jumps, even if it chooses
>> a non-traditional time to label some of its seconds once every year and
>> a half or two.
> 
> I think it is reasonable to say that UTC's labelling of seconds is
> discontinuous. For timescales that use simple ancient sexagesimal notation
> you can write down some straightforward formulae mapping between a count
> of seconds and a broken down time. If you try to do the same for UTC you
> have to write down something that is piecewise linear with exceptions. It
> isn't a continuous map like other timescales.

UTC defines second labeling such that it isn't technically discontinuous. It is 
an irregular radix that requires non-naieve math to properly convert to a 
count. UTC broke with thousands (or at the very least hundreds[*]) of years of 
time keeping practice by making what had been a completely regular radix 
notation for the time and converted to an irregular radix with known rules, but 
no known schedule.

Still a pain no matter what you call it.

Warner

[*] An interesting side note about days: The ancient Egyptians regarded light 
and night as two separate realms rather than as being two halves of the same 
day. The notion of the synodic day thus dates only from the new kingdom, 
somewhere around 1400BC where the two different realms, each governed by 12 
starts was replaced by a system that unified them under 24 stars 
(http://www.scientificamerican.com/article/experts-time-division-days-hours-minutes/).
 It wasn't until the Greeks around 100BC that we see the hours becoming fixed 
length (although average people used seasonally varying hours for hundreds of 
years after this: not until mechanical clocks of the 14th century did this 
stop). From the 16th century until 1972, though, minutes and seconds were 
uniform set by the fixed hour. So although sexagesimal notation for time was 
invented thousands of years ago around the birth of Christ, it wasn't until 
really good mechanical clocks of the 16th century that one could say that the
  radix was truly fixed. Which leads me to why I equivocated.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Future time

[Rob Seaman]

On Jan 20, 2014, at 10:43 AM, Warner Losh  wrote:

> [*] An interesting side note about days: The ancient Egyptians regarded light 
> and night as two separate realms rather than as being two halves of the same 
> day. The notion of the synodic day thus dates only from the new kingdom,

While one could perhaps define a notion somewhat like a synodic period for the 
Ptolemaic system of deferent and epicycles (or perhaps one could not), the 
understanding of the wide variety of such periods in the solar system had to 
wait for Copernicus to put the Sun at its center.  Ptolemy was 1500 years after 
the New Kingdom, and Copernicus about 1500 years after Ptolemy.

That said, whether humans had any notion or not, day on Earth has always been 
the synodic day.  The Earth rotates, and as it revolves around the Sun one 
rotation per year is unwrapped.

> somewhere around 1400BC where the two different realms, each governed by 12 
> starts was replaced by a system that unified them under 24 stars 
> (http://www.scientificamerican.com/article/experts-time-division-days-hours-minutes/).

It would be reasonable to say that we still treat night and day as two 
different realms, hence the idiom “as different as night and day”.  In that 
case the synodic cadence applies to each separately.

> It wasn't until the Greeks around 100BC that we see the hours becoming fixed 
> length (although average people used seasonally varying hours for hundreds of 
> years after this: not until mechanical clocks of the 14th century did this 
> stop). From the 16th century until 1972, though, minutes and seconds were 
> uniform set by the fixed hour. So although sexagesimal notation for time was 
> invented thousands of years ago around the birth of Christ, it wasn't until 
> really good mechanical clocks of the 16th century that one could say that the 
> radix was truly fixed. Which leads me to why I equivocated.

Hours can be fixed length or unequal, day can be deemed to start at sunrise, 
sunset, noon or midnight, the representation of time can be sexagesimal or a 
count since an epoch, static time zone offsets can be applied, periodic DST 
corrections made, eccentricity and obliquity can overlay the Sun’s apparent 
place in the sky with a charming analemma, and geophysics and Lunar tides can 
make it all wobble.

And underneath it all the day is a synodic day.  Deploying a civil time system 
that says otherwise would be a fundamental error of engineering.  Leap seconds 
are a means to an end.

Rob

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs