Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Poul-Henning Kamp]

In message <20140112064503.gb23...@ucolick.org>, Steve Allen writes:

>How they handle the leap second issue will assert whether humanity has
>any intent of keeping the meaning of the word "day" to be based on the
>rotation of the earth.

No, it will decide who gets to decide when "day" is:  The local and
therefore presumably legitimate government, or a bunch of scientists.

"day" is defined by what you clock shows, and clocks don't run on UTC,
they run on:

   UTC + some_constant_to_make_it_day_when_our_government_wants_it_to_be_day


Dropping leapseconds will only cause approx 0.5% more frequent
adjustments to that constant than the previous century has seen.

-- 
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] presentations from AAS Future of Time sessions

[Poul-Henning Kamp]

In message <52d20beb.60...@edlmax.com>, Brooks Harris writes:


>Yes, in my opinion its unfortunate they chose to use the term "UTC" in
>that context.

They chose UTC because they meant UTC.

I have this directly from multiple persons who were involved back
then, including Dennis Ritchie who gave me the full sordid details
about the early UNIX' requirement of weekly recompiles to update
the epoch of the timekeeping.

The reason why they didn't cater to leap-seconds ?

They hadn't heard about them at the time.

And even if they had, they likely wouldn't have bothered, since the
PDP-11's kept time based on the mains grid frequency and Ken Thompsons
wrist-watch.

The trouble starts when Bell Labs starts to commercialize UNIX,
polishes the manual pages and goldplates them as "System V Interface
Definition" in 1985, without checking if there are any implicit
references to Ken's watch that needed to be resolved.

Interestingly, leapseconds appear in network time protocols for the
first time in 1985, where previous prototypes does not have support
for them, despite the leapseconds in '81, '82 and '83.

Later the manual pages also became X/Open, which were fostered by
a group of UNIX vendors who wanted BSD networking rather than
STREAMS, because the former worked while the latter really didn't,
and they didn't notice the bit about leap-seconds either.

Eventually it all became dumbed down to POSIX so that Windows NT,
VMS and MVS could also qualify, which is were all the crappy APIs
(timespec, clock_t etc.) comes from as far as I remember.

...and then the dot-com boom happened, multiplying the cadre of programmers
by a factor 1000 and reducing the average knowledge and skill level by
the same factor, at the same time as leap-seconds took a break.

The rest is (also) history.

But time_t has always been UTC, because it was meant to be UTC.

-- 
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] presentations from AAS Future of Time sessions

[Steve Allen]

On Sat 2014-01-11T21:43:02 -0800, Brooks Harris hath writ:
> Any help getting to the bottom of this appreciated.

It's history, and it's confused.  Measurement techniques were crude
and people were not cognizant that there was more than one thing being
measured.  Measurement techniques are vastly improved and some people
understand better, but even the best current knowledge cannot
unconfuse the folks in the past or be sure how to interpret their
understanding using a modern vocabulary and reference frame.

NASA technical report number 70 by Hans D.  Preuss of the Department
of Geodetic Science at Ohio State University "The Determination and
Distribution of Precise Time" is relevant to read to see how badly
confused the situation was in the 1960s
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19670028967_1967028967.pdf

NIST has many of the old NBS publications scanned and online at their
website, and many of the announcements of rationales and dates when
decisions were made to change the radio broadcasts are scattered among
those.  Their publication with most dense collection of such facts is
NBS Monograph 140 which can be found at
http://digicoll.manoa.hawaii.edu/techreports/PDF/NBS140.pdf

But nobody is going to reset their clocks based on a new understanding
of when an epoch was nor what kinds of seconds were being counted.
Tabulating historic differences between the values of various time
scales is of little relevance to the decision before the ITU-R.
How they handle the leap second issue will assert whether humanity has
any intent of keeping the meaning of the word "day" to be based on the
rotation of the earth.

--
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] presentations from AAS Future of Time sessions

[Warner Losh]

On Jan 11, 2014, at 8:28 PM, Brooks Harris wrote:

> On 2014-01-11 08:32 AM, Joseph Gwinn wrote:
>> On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
>> 
>>> On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
>>> 
>>> 
 'Proscribe’ and 'prescribe' are distinct words:
  
 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
 proscribe the use of pencils on exams.”
  
 'Prescribe' means to lay out specifications or rules about 
 something. "In the manner prescribed by law.”
  
 I don’t know the context of the sentence the Magnus refers to.
 
>>> Prescribe is the word I intended. POSIX mandates, requires, 
>>> prescribes that time is UTC.
>>> 
>> No.  While POSIX broken-down time resembles UTC, the underlying 
>> timescale (Seconds since the Epoch) is *not* UTC, in that every day 
>> contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
>> applied.
>> 
>> The confusion arises because the POSIX Epoch is defined using UTC.  But 
>> the progression rule is a form of TAI (with unknown but constant 
>> offset).  POSIX background information follows.
>> 
>> 
>> URL of index page: 
>> 
>> 
>> 
>> 
>> >From POSIX Base Definitions volume: 
>> 
>> 3.149 Epoch
>> The time zero hours, zero minutes, zero seconds, on January 1, 1970 
>> Coordinated Universal Time (UTC).
>> 
>> 
>> >From the General Concepts volume:
>> 
>> 4.14 Seconds Since the Epoch
>> A value that approximates the number of seconds that have elapsed since 
>> the Epoch. A Coordinated Universal Time name (specified in terms of 
>> seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 
>> 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is 
>> related to a time represented as seconds since the Epoch, according to 
>> the expression below.
>> 
>> If the year is <1970 or the value is negative, the relationship is 
>> undefined. If the year is >=1970 and the value is non-negative, the 
>> value is related to a Coordinated Universal Time name according to the 
>> C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and 
>> tm_year are all integer types:
>> 
>> 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 relationship between the actual time of day and the current value 
>> for seconds since the Epoch is unspecified.
>> How any changes to the value of seconds since the Epoch are made to 
>> align to a desired relationship with the current actual time is 
>> implementation-defined. As represented in seconds since the Epoch, each 
>> and every day shall be accounted for by exactly 86400 seconds.
>> 
>> Note:
>> The last three terms of the expression add in a day for each year that 
>> follows a leap year starting with the first leap year since the Epoch. 
>> The first term adds a day every 4 years starting in 1973, the second 
>> subtracts a day back out every 100 years starting in 2001, and the 
>> third adds a day back in every 400 years starting in 2001. The 
>> divisions in the formula are integer divisions; that is, the remainder 
>> is discarded leaving only the integer quotient.
>> 
>> 
>> History:  
>> 
>> 
>> 
>> Joe Gwinn  
>> ___
>> LEAPSECS mailing list
>> 
>> LEAPSECS@leapsecond.com
>> http://six.pairlist.net/mailman/listinfo/leapsecs
>> 
>> 
>> 
>> 
> 
> Yes, in my opinion its unfortunate they chose to use the term "UTC" in that 
> context.
> 
> What I've never seen written anywhere is something rather obvious - that the 
> formula shown in 4.14 Seconds Since the Epoch is the formula for the 
> Gregorian calendar timescale.. mktime() and gmtime() (and related) treat the 
> time_t Seconds value as an uncompensated-for-Leap-Seconds Gregorian calendar 
> timescale as defined and codified in ISO 8601, section 3.2.1 The Gregorian 
> calendar.
> 
> Its actually explained better in the "Rationale: Base Definitions", section, 
> A.4.15 Seconds Since the Epoch. -
> 
> IEEE Std 1003.1, 2013 Edition
> http://pubs.opengroup.org/onlinepubs/9699919799/
> (Select "Rationale" in the upper left pane, then "Rationale for Base 
> Definitions" in the lower-left pane, scroll down to  A.4.15 Seconds Since the 
> Epoch) 
> 
> There they say "Broken-down POSIX time is therefore not necessarily UTC, 
> despite its appearance." Note the use of the phrase "POSIX time", a much 
> better term for it, in my opinion., since that phrase encompasses the 
> counting method and the definition of its origin - "the Epoch".  But that's 
> not the end of the story.
> 
> In the absence of any Leap Second compensation applied to the time_t value, 
> the "appearance" is the Gregorian calendar timescale. But the phrase "not 
> necessarily UTC" signals that *if* Leap Second compensation has been applied 
> to time_t a

Re: [LEAPSECS] Standards of time zones -Brooks Harris

[Brooks Harris]

On 2014-01-11 12:35 PM, Tom Van Baak wrote:

That's disconcerting.

Brooks,

Nice that the list has come back to life. Looking back on your original 
question about UTC documentation, you never mentioned what your actual 
application is. I think it would be helpful if you could state what your 
problem or your goal is.


I've been in the video business all my career. In this world, the 
frequencies you deal with are a crazy mix, coupled with requirements of 
pairs of things (like interlaced field/frame video formats) and audio 
sample rates. One nasty frequency that causes no end of headaches is 
3/1001, the frame rate of NTSC television, the video rate you are 
probably watching in the US, Japan and other large places. That "1001" 
ratio creates all sorts of mathematical and implementation trouble. 
Europe and others run at 25/1, with is easy in some ways, by the odd 
number (25) causes other challenges. Keeping everything in sync and 
displaying is a wild world of interlocking standards.


I've been on technical committees for years. Typically "date-time" is 
not a hot topic - the video (and sound) just roll from some arbitrary 
moment, and any "date" applied is *very loosely* coupled to the media. 
But now, everyone is interested in synchronizing media with date-time. 
In particular, they want to use In particular, using 1588/PTP, and they 
want "local time". Well, guess what? "Media" is way easier (for those of 
us steeped in it) than "date-time".


Partly, the challenge is that time-keeping is "seemingly simple, yet 
deceptively complex". Getting folks to grasp the scale of difficulties 
is a challenge - "just put the date on it!". But even as you're willing 
to tackle it the difficulties mount, partly, as I've said, the 
terminology and standards are fractured. So, I'm reaching out to see if 
there's some way to fix that part.



There are a lot of ways to handle UTC. In some respects it's easier than the 
Gregorian calendar.


6. Rapid UTC (F. Arias, A. Harmegnies, G. Panfilo, G. Petit, L.
Tisserand) describes an effort to improve UTC, so maybe there's work
going on to help inform the debate further.

Rapid UTC is not an issue this list needs to worry about. Essentially it just 
modernizes the method by which the various UTC(k) labs steer their local or 
national timescales (at the nanosecond level), a reduction from one month to 
under a week.


It seems like its related to Rob Seaman's earlier proposal to refine the 
update schedule of Leap Second insertion. Maybe it is, or maybe its one 
place his suggestion should be considered?





7. New proposed definition of UTC (F. Arias, W. Lewandowski) states the
''It was decided to postpone the decision until the World
Radiocommunication Conference 2015" . There, at least, are two names
officially related to the debate.

Are those relevant? Is there communication with any of these people?

Many of us know all those involved. It's a small world and everyone is trying 
to be helpful.


So maybe, just maybe, the list participants could find an audience 
there, and something could be done to head off the "kill Leap Seconds" 
movement? That's my hope, somehow.


-Brooks



/tvb

___
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] Standards of time zones -Brooks Harris

[Tom Van Baak]

> That's disconcerting.

Brooks,

Nice that the list has come back to life. Looking back on your original 
question about UTC documentation, you never mentioned what your actual 
application is. I think it would be helpful if you could state what your 
problem or your goal is. There are a lot of ways to handle UTC. In some 
respects it's easier than the Gregorian calendar.

> 6. Rapid UTC (F. Arias, A. Harmegnies, G. Panfilo, G. Petit, L. 
> Tisserand) describes an effort to improve UTC, so maybe there's work 
> going on to help inform the debate further.

Rapid UTC is not an issue this list needs to worry about. Essentially it just 
modernizes the method by which the various UTC(k) labs steer their local or 
national timescales (at the nanosecond level), a reduction from one month to 
under a week.

> 7. New proposed definition of UTC (F. Arias, W. Lewandowski) states the 
> ''It was decided to postpone the decision until the World 
> Radiocommunication Conference 2015" . There, at least, are two names 
> officially related to the debate.
> 
> Are those relevant? Is there communication with any of these people?

Many of us know all those involved. It's a small world and everyone is trying 
to be helpful.

/tvb

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

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Warner Losh]

Thanks Joseph...  That gives some good details and history. For people that 
want or need UTC, however, it does make it impossible to get right in all the 
details. As more applications and situations care, this "simplification" of UTC 
is causing many problems. It also shows that it would be politically impossible 
to fix.

I had a longer reply, which I deleted, since while arguing over the finer 
points showed we were really saying the same bigger point: POSIX time_t doesn't 
model UTC very well at all, especially where UTC differs from pre-1972-UTC 
semantics where every minute had 60 seconds, every hours 60 equal-length 
minutes, etc (eg leap seconds) and exact, faithful rendition of UTC is desired. 
All that's possible is an approximate rendition where some aspect of "pure" UTC 
is sacrificed, the exact one that's sacrificed depends on the application's 
needs...

Warner

On Jan 11, 2014, at 11:16 AM, Joseph Gwinn wrote:

> On Sat, 11 Jan 2014 10:39:32 -0700, Warner Losh wrote:
>> 
>> On Jan 11, 2014, at 9:32 AM, Joseph Gwinn wrote:
>> 
>>> On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
 
 On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
 
> 'Proscribe’ and 'prescribe' are distinct words:
> 
> 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
> proscribe the use of pencils on exams.”
> 
> 'Prescribe' means to lay out specifications or rules about 
> something. "In the manner prescribed by law.”
> 
> I don’t know the context of the sentence the Magnus refers to.
 
 Prescribe is the word I intended. POSIX mandates, requires, 
 prescribes that time is UTC.
>>> 
>>> No.  While POSIX broken-down time resembles UTC, the underlying 
>>> timescale (Seconds since the Epoch) is *not* UTC, in that every day 
>>> contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
>>> applied.
>> 
>> That's the problem with POSIX time_t. It specifies a mapping from UTC 
>> to time_t, but the mapping isn't 1-1 onto. It tries to be UTC, but 
>> also tries to paper over leap seconds by pretending they don't exist. 
>> That's part of the craziness of POSIX time_t. It specifies something 
>> that doesn't match UTC, but is expected to be much like UTC. It also 
>> is UTC in the sense that it tracks UT1 within a second (ignoring 
>> errors in realization on a specific system). It is a poorly modeled 
>> approximation of UTC that makes certain compromises to get a 'simple 
>> math' property, but pretends that leap seconds don't exist and are an 
>> implementation detail specifically not specified.
> 
> Trying to force POSIX time into the UTC mold isn't going to go well.  
> 
> Read the official definition slowly, without the assumption that the 
> committee really meant UTC but didn't know how to say it.  Every word 
> was debated.  See the appended section of Rationale.
> 
> 
>>> The confusion arises because the POSIX Epoch is defined using UTC.  But 
>>> the progression rule is a form of TAI (with unknown but constant 
>>> offset).  POSIX background information follows.
>> 
>> The progression rule doesn't say that. The offset to TAI changes at 
>> each leap second. So it is mostly kinda sorta TAI with a fixed 
>> offset, until a leap second happens. Then the offset changes.
> 
> The definition does not actually mention TAI (although it was proposed 
> to do so).  I'm just pointing out that POSIX time is in effect a form 
> of TAI.  Granted that the offset jumps on leap seconds if one is fed 
> from UTC (via GPS), but this causes little trouble.  If fed from GPS 
> System Time, the offset never changes.
> 
> 
>>> URL of index page: 
>>> 
>>> 
 From POSIX Base Definitions volume: 
>>> 
>>> 3.149 Epoch
>>> The time zero hours, zero minutes, zero seconds, on January 1, 1970 
>>> Coordinated Universal Time (UTC).
>>> 
>>> 
 From the General Concepts volume:
>>> 
>>> 4.14 Seconds Since the Epoch
>>> A value that approximates the number of seconds that have elapsed since 
>>> the Epoch. A Coordinated Universal Time name (specified in terms of 
>>> seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 
>>> 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is 
>>> related to a time represented as seconds since the Epoch, according to 
>>> the expression below.
>>> 
>>> If the year is <1970 or the value is negative, the relationship is 
>>> undefined. If the year is >=1970 and the value is non-negative, the 
>>> value is related to a Coordinated Universal Time name according to the 
>>> C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and 
>>> tm_year are all integer types:
>>> 
>>> 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
>> 
>> This section says UTC and defines how it is related to UTC...
> 
> The key word is "related". 

[LEAPSECS] what happened to GMT

[Steve Allen]

On Sat 2014-01-11T18:49:58 +, Michael Spacefalcon hath writ:
> But does this ``Zulu'' mean GMT (a natural phenomenon
> whose meaning is independent of human whim)

If only it were so, but looking back at the 1884 International
Meridian Conference it appears that the reason Simon Newcomb vanished
from the meetings was that he agreed when Janssen said it wasn't as
simple as that.  "A circle has no end" so somehow there must be a
human convention for where the "point de depart", the origin, will be.

During WW2 when the Airy transit at Greenwich was not in operation the
BIH "Heure Definitive" continued to exist via the other observatories.
The final Airy observation was 1954-03-30.  By 1956 the UK transit
astronomers then moved to Herstmonceux noted that the current offset
of UT from GMT was small, and admitted they would not even try to
establish the exact offset from Greenwich
http://adsabs.harvard.edu/full/1957Obs77...31A
It was far too late in 1971 when their successors again wrote about it
http://adsabs.harvard.edu/abs/1971Obs91..155O
basically saying "We did what?"  because by then the DOPPLER satellite
tracking had begun to supersede optical transit measures.  The BIH
change in weighting from meridian transit observations to satellite,
lunar, and VLBI is evident in these 1984 plots from Martine Feissel:
http://www.ucolick.org/~sla/leapsecs/MFatt2.pdf
Hiding in those charts is the shift of all terrestrial longitudes from
their nonrelativistic Greenwich-based local values to their
relativistic geocentric global values.

--
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] Non-POSIX UNIX time

[Poul-Henning Kamp]

In message <140849.aa05...@ivan.harhan.org>, Michael Spacefalcon writes:

>With all the discussion about POSIX time again, I present for contrast
>how time_t is defined on Non-POSIX UNIX systems.  Here is the man page:

... from Michaels Private Unix.

Don't feed the troll.

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

[LEAPSECS] Non-POSIX UNIX time

[Michael Spacefalcon]

With all the discussion about POSIX time again, I present for contrast
how time_t is defined on Non-POSIX UNIX systems.  Here is the man page:

.\" @(#)unixtime.7  1.2 (IFCTF) 2013/01/19
.\"
.hw time-stamp
.TH UNIXTIME 7 "January 19, 2013"
.UC 8
.SH NAME
time_t \- representation of time in UNIX
.SH DESCRIPTION
``Everyone'' knows that UNIX represents civil time
(that is, time intended for display to casual human users)
internally as a linear count of seconds since Zulu midnight,
January 1, A.D. 1970, i.e., since \%1970-01-01T00:00:00Z.
But does this ``Zulu'' mean GMT (a natural phenomenon
whose meaning is independent of human whim) or UTC (a man-made
political construct)?
And does ``seconds'' mean counts of periods of radiation emitted
by Cesium atoms, 1/86400th fractions of naturally-occurring cycles
of day and night, or the rotation of the hands of some
``official civil time'' clock by a certain angle?
.SH HISTORY
As a matter of historical precedent, it is absolutely certain
that in the early days of UNIX, computer clocks were set from
wall clocks or wristwatches, \fInot\fP the other way around.
Therefore, whatever abstract philosophical definition
the Founding Fathers of UNIX may have had in mind,
the meaning of
.B time_t
was defined
.I de facto
by the broken-down-time algorithm implemented in the
.IR ctime (3)
family of functions and its inverse implemented in the
.IR date (1)
command.
In other words, the de facto meaning of
.B time_t
is whatever number results when the operator looks at a wall clock
or wristwatch and enters the observed local civil time into
.IR date .
.PP
The original
.I de facto
definition of
.B time_t
can thus be formally stated as follows:
.IP 1.
It is the rotation angle of the hands of a non-DST-observing
civil time clock, i.e., time-of-day rather than physical time interval.
.IP 2.
One count of
.B time_t
represents an interval of civil time during which the hour hand of
an official civil time clock rotates by 30 arc-seconds, while
the minute hand of the same clock rotates by 6 arc-minutes,
\fBcompletely irrespective of what this time interval may happen to
equal in SI seconds.\fP
.IP 3.
The
.B time_t
epoch is the moment when the official civil time clocks at
Murray Hill, New Jersey displayed \%1969-12-31T19:00:00 exactly,
\fBcompletely irrespective of what this moment may correspond to
on more formally defined timescales.\fP
.SH CONTROVERSY
Being merely a representation of civil time that has an uncertainty
on the order of seconds and is completely meaningless on even finer
scales, the traditional UNIX time is clearly unsuitable for
applications that require time in a Newtonian or Einsteinian
physical sense, such as physics experiments, air traffic control, etc.
.PP
In the opinion of Michael Spacefalcon, the maintainer of
4.3BSD-Quasijarus and the author of this manual page,
the least invasive and least disruptive way to solve that problem would be
to implement an entirely separate timekeeping system for physical interval
time, entirely disconnected from traditional UNIX time, keeping the
latter strictly for \fIcivil\fP (or social) purposes for which
it has been predominantly used.
.PP
Unfortunately, a strong technocratic lobby has been relentlessly
pushing in a different direction: they assert that the counts of
.B time_t
should be SI seconds, rather than seconds of mean solar time
(1/86400th fractions of a day) whose duration in Newtonian physical time
is variable and somewhat unpredictable thanks to the irregularities
in Earth's rotation,
and they demand that ``POSIX'' time be defined in terms of UTC,
which is very problematic because the latter is a purely man-made
construct that is highly susceptible to political machinations.
.PP
A commonly heard proposal is to switch
.B time_t
to a linear count of SI seconds, or more precisely, a count of
SI seconds
.I
as reckoned by the technocratic cartel's worldwide ensemble of atomic clocks
(never mind that such a count would instantly become devoid of all meaning
if those clocks were all powered off for just a couple of minutes),
and to produce time for human display (at least for those users
who operate in jurisdictions that still use Mean Solar Time as the basis
of their legal time, even if it's indirect MST in the form of UTC with
leap seconds) by having
.IR ctime (3)
or other similar functions perform leap second manipulations.
.PP
At first glance the above proposal sounds like a good idea,
and I have seriously considered it at one time as well.
After all, given that MST is not directly and continuously observable,
the most expedient method of producing a practical realization thereof
that is continuously accessible in real time is to derive it algorithmically
from a stable interval time source such as an atomic clock.
If in today's society the approximation to Mean Solar Time that serves
as most people's civil time is algorithmically derived from stable
interval time, wouldn't it make more sense to adopt the latter as the
fun

Re: [LEAPSECS] Standards of time zones -Brooks Harris

[Brooks Harris]

On 2014-01-09 10:28 PM, Steve Allen wrote:

On Thu 2014-01-09T01:56:03 -0800, Brooks Harris hath writ:

In 2011 you posted to the list a link to the 2011 ITU-R CACE issued
Circular 539

http://six.pairlist.net/pipermail/leapsecs/2011-June/003058.html

Whats the current status of that? Still on hold?

That was one of the rare ITU-R documents which is released in advance
of a decision.  The usual ITU-R process is so closed that I can't say
I understand it, so anything I know is incomplete.


That's disconcerting.

I note two relevant entries in the BIPM Annual Report on Time Activities 
Volume 7 2012 -


6. Rapid UTC (F. Arias, A. Harmegnies, G. Panfilo, G. Petit, L. 
Tisserand) describes an effort to improve UTC, so maybe there's work 
going on to help inform the debate further.


7. New proposed definition of UTC (F. Arias, W. Lewandowski) states the 
''It was decided to postpone the decision until the World 
Radiocommunication Conference 2015" . There, at least, are two names 
officially related to the debate.


Are those relevant? Is there communication with any of these people?

-Brooks



In this case the issue of the open CACE seems to have been cued by the
unusual fact that the ITU-R bureacrats could see that the delegates
from the nations at the 2012 Radiocommunication Assembly were going to
be asked to vote on a draft proposed revision that had not achieved
consensus at the Working Party or Study Group levels.  The subsequent
press reports about the RA finding itself split 3 ways (much like
several other committees of experts had been previously) and then
declining to vote seem to indicate that any hope for resolution
embodied in issuing that CACE did not come to fruition.

Follwing the RA was the WRC, and they produced Resolution 653
[COM6/20] (WRC-12) which has become WRC-15 Agenda Item 1.14.  The
wording of Resolution 653 seems extremely strong, basically lighting a
fire under SG7 and WP7A and telling them to engage with other
organizations and do whatever is necessary to give better options to
the delegates who come to the 2015 RA.  The next layer after the WRC
who turned 653 into Agenda Item 1.14 toned down the intensity a little.

Google hasn't shown me anything released since then, so whatever
negotiations are going on are staying out of sight.

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




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

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Sat, 11 Jan 2014 10:39:32 -0700, Warner Losh wrote:
> 
> On Jan 11, 2014, at 9:32 AM, Joseph Gwinn wrote:
> 
>> On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
>>> 
>>> On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
>>> 
 'Proscribe’ and 'prescribe' are distinct words:
 
 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
 proscribe the use of pencils on exams.”
 
 'Prescribe' means to lay out specifications or rules about 
 something. "In the manner prescribed by law.”
 
 I don’t know the context of the sentence the Magnus refers to.
>>> 
>>> Prescribe is the word I intended. POSIX mandates, requires, 
>>> prescribes that time is UTC.
>> 
>> No.  While POSIX broken-down time resembles UTC, the underlying 
>> timescale (Seconds since the Epoch) is *not* UTC, in that every day 
>> contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
>> applied.
> 
> That's the problem with POSIX time_t. It specifies a mapping from UTC 
> to time_t, but the mapping isn't 1-1 onto. It tries to be UTC, but 
> also tries to paper over leap seconds by pretending they don't exist. 
> That's part of the craziness of POSIX time_t. It specifies something 
> that doesn't match UTC, but is expected to be much like UTC. It also 
> is UTC in the sense that it tracks UT1 within a second (ignoring 
> errors in realization on a specific system). It is a poorly modeled 
> approximation of UTC that makes certain compromises to get a 'simple 
> math' property, but pretends that leap seconds don't exist and are an 
> implementation detail specifically not specified.

Trying to force POSIX time into the UTC mold isn't going to go well.  

Read the official definition slowly, without the assumption that the 
committee really meant UTC but didn't know how to say it.  Every word 
was debated.  See the appended section of Rationale.


>> The confusion arises because the POSIX Epoch is defined using UTC.  But 
>> the progression rule is a form of TAI (with unknown but constant 
>> offset).  POSIX background information follows.
> 
> The progression rule doesn't say that. The offset to TAI changes at 
> each leap second. So it is mostly kinda sorta TAI with a fixed 
> offset, until a leap second happens. Then the offset changes.

The definition does not actually mention TAI (although it was proposed 
to do so).  I'm just pointing out that POSIX time is in effect a form 
of TAI.  Granted that the offset jumps on leap seconds if one is fed 
from UTC (via GPS), but this causes little trouble.  If fed from GPS 
System Time, the offset never changes.


>> URL of index page: 
>> 
>> 
>>> From POSIX Base Definitions volume: 
>> 
>> 3.149 Epoch
>> The time zero hours, zero minutes, zero seconds, on January 1, 1970 
>> Coordinated Universal Time (UTC).
>> 
>> 
>>> From the General Concepts volume:
>> 
>> 4.14 Seconds Since the Epoch
>> A value that approximates the number of seconds that have elapsed since 
>> the Epoch. A Coordinated Universal Time name (specified in terms of 
>> seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 
>> 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is 
>> related to a time represented as seconds since the Epoch, according to 
>> the expression below.
>> 
>> If the year is <1970 or the value is negative, the relationship is 
>> undefined. If the year is >=1970 and the value is non-negative, the 
>> value is related to a Coordinated Universal Time name according to the 
>> C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and 
>> tm_year are all integer types:
>> 
>> 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
> 
> This section says UTC and defines how it is related to UTC...

The key word is "related".  This is not equality, and the choice of 
weasel word was deliberate.


>> The relationship between the actual time of day and the current value 
>> for seconds since the Epoch is unspecified.
> 
> This sentence is the most lame part of the spec. We define this 
> value, but it doesn't have to match? Most implementors I've talked 
> with have suggested that this means "the error is not bounded" rather 
> than "you can have random values second to second"

There is a long history.  It was a big fight.  The trail is in the 
email archives, if anybody has the energy.  

Suffice it to say that the Time Folk kept quarreling about the One True 
Clock, while ignoring the needs of the POSIX world, until the POSIX 
Committee threw the Time Folk out in exasperation and stuck with what 
they had inherited from UNIX.

I did manage to fix the leap year computation (restore the 400-year 
rule), and remove the nonsense about double leap seconds.

Somewhere else, 


>> How any changes to the value of seconds since the Epoch are made to 
>> align to a

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Steve Allen]

On Sat 2014-01-11T10:39:32 -0700, Warner Losh hath writ:
> This allows all kinds of implementations, except one that assigns a
> unique value to the leap second.  It allows one to repeat a second
> (either the last one of the day of the leap second, or the first one
> of the next day (both common) or really any other second).  It also
> allows the google run a little fast until you accumulate the new
> second.

actually a little slow, which means that Google's leap smear
appropriately evokes how the dialog from Disney's Haunted
Mansion is analogous to leap seconds in POSIX:

Your cadaverous pallor betrays an aura of foreboding, almost as
though you sense a disquieting metamorphosis.  Is this haunted
room actually stretching?  Or is it your imagination?  And
consider this dismaying observation: this chamber has no windows,
and no doors.  Which offers you this chilling challenge: to find a
way out!  Of course, there's always my way.

--
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] presentations from AAS Future of Time sessions

[Warner Losh]

On Jan 11, 2014, at 9:32 AM, Joseph Gwinn wrote:

> On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
>> 
>> On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
>> 
>>> 'Proscribe’ and 'prescribe' are distinct words:
>>> 
>>> 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
>>> proscribe the use of pencils on exams.”
>>> 
>>> 'Prescribe' means to lay out specifications or rules about 
>>> something. "In the manner prescribed by law.”
>>> 
>>> I don’t know the context of the sentence the Magnus refers to.
>> 
>> Prescribe is the word I intended. POSIX mandates, requires, 
>> prescribes that time is UTC.
> 
> No.  While POSIX broken-down time resembles UTC, the underlying 
> timescale (Seconds since the Epoch) is *not* UTC, in that every day 
> contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
> applied.

That's the problem with POSIX time_t. It specifies a mapping from UTC to 
time_t, but the mapping isn't 1-1 onto. It tries to be UTC, but also tries to 
paper over leap seconds by pretending they don't exist. That's part of the 
craziness of POSIX time_t. It specifies something that doesn't match UTC, but 
is expected to be much like UTC. It also is UTC in the sense that it tracks UT1 
within a second (ignoring errors in realization on a specific system). It is a 
poorly modeled approximation of UTC that makes certain compromises to get a 
'simple math' property, but pretends that leap seconds don't exist and are an 
implementation detail specifically not specified.

> The confusion arises because the POSIX Epoch is defined using UTC.  But 
> the progression rule is a form of TAI (with unknown but constant 
> offset).  POSIX background information follows.

The progression rule doesn't say that. The offset to TAI changes at each leap 
second. So it is mostly kinda sorta TAI with a fixed offset, until a leap 
second happens. Then the offset changes.

> URL of index page: 
> 
> 
>> From POSIX Base Definitions volume: 
> 
> 3.149 Epoch
> The time zero hours, zero minutes, zero seconds, on January 1, 1970 
> Coordinated Universal Time (UTC).
> 
> 
>> From the General Concepts volume:
> 
> 4.14 Seconds Since the Epoch
> A value that approximates the number of seconds that have elapsed since 
> the Epoch. A Coordinated Universal Time name (specified in terms of 
> seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 
> 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is 
> related to a time represented as seconds since the Epoch, according to 
> the expression below.
> 
> If the year is <1970 or the value is negative, the relationship is 
> undefined. If the year is >=1970 and the value is non-negative, the 
> value is related to a Coordinated Universal Time name according to the 
> C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and 
> tm_year are all integer types:
> 
> 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

This section says UTC and defines how it is related to UTC...

> The relationship between the actual time of day and the current value 
> for seconds since the Epoch is unspecified.

This sentence is the most lame part of the spec. We define this value, but it 
doesn't have to match? Most implementors I've talked with have suggested that 
this means "the error is not bounded" rather than "you can have random values 
second to second"

> How any changes to the value of seconds since the Epoch are made to 
> align to a desired relationship with the current actual time is 
> implementation-defined. As represented in seconds since the Epoch, each 
> and every day shall be accounted for by exactly 86400 seconds.

This section says you are on your own for coping with leap seconds. This allows 
all kinds of implementations, except one that assigns a unique value to the 
leap second. It allows one to repeat a second (either the last one of the day 
of the leap second, or the first one of the next day (both common) or really 
any other second). It also allows the google run a little fast until you 
accumulate the new second.

> Note:
> The last three terms of the expression add in a day for each year that 
> follows a leap year starting with the first leap year since the Epoch. 
> The first term adds a day every 4 years starting in 1973, the second 
> subtracts a day back out every 100 years starting in 2001, and the 
> third adds a day back in every 400 years starting in 2001. The 
> divisions in the formula are integer divisions; that is, the remainder 
> is discarded leaving only the integer quotient.
> 
> 
> History:  
> 
> Joe Gwinn  
> ___
> LEAPSECS mailing list
> LEAPSECS@leapsecond.com
> http://six.pairlist.net/mailman/listinfo/leapsecs

_

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[Joseph Gwinn]

On Fri, 10 Jan 2014 21:35:25 -0700, Warner Losh wrote:
> 
> On Jan 10, 2014, at 8:35 PM, Skip Newhall wrote:
> 
>> 'Proscribe’ and 'prescribe' are distinct words:
>>  
>> 'Proscribe' means to forbid, disallow, or prohibit. “School rules 
>> proscribe the use of pencils on exams.”
>>  
>> 'Prescribe' means to lay out specifications or rules about 
>> something. "In the manner prescribed by law.”
>>  
>> I don’t know the context of the sentence the Magnus refers to.
> 
> Prescribe is the word I intended. POSIX mandates, requires, 
> prescribes that time is UTC.

No.  While POSIX broken-down time resembles UTC, the underlying 
timescale (Seconds since the Epoch) is *not* UTC, in that every day 
contains exactly 60*60*24= 86,400 seconds.  Leap seconds are *not* 
applied.

The confusion arises because the POSIX Epoch is defined using UTC.  But 
the progression rule is a form of TAI (with unknown but constant 
offset).  POSIX background information follows.


URL of index page: 


>From POSIX Base Definitions volume: 

3.149 Epoch
The time zero hours, zero minutes, zero seconds, on January 1, 1970 
Coordinated Universal Time (UTC).


>From the General Concepts volume:

4.14 Seconds Since the Epoch
A value that approximates the number of seconds that have elapsed since 
the Epoch. A Coordinated Universal Time name (specified in terms of 
seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 
1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is 
related to a time represented as seconds since the Epoch, according to 
the expression below.

If the year is <1970 or the value is negative, the relationship is 
undefined. If the year is >=1970 and the value is non-negative, the 
value is related to a Coordinated Universal Time name according to the 
C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and 
tm_year are all integer types:

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 relationship between the actual time of day and the current value 
for seconds since the Epoch is unspecified.
How any changes to the value of seconds since the Epoch are made to 
align to a desired relationship with the current actual time is 
implementation-defined. As represented in seconds since the Epoch, each 
and every day shall be accounted for by exactly 86400 seconds.

Note:
The last three terms of the expression add in a day for each year that 
follows a leap year starting with the first leap year since the Epoch. 
The first term adds a day every 4 years starting in 1973, the second 
subtracts a day back out every 100 years starting in 2001, and the 
third adds a day back in every 400 years starting in 2001. The 
divisions in the formula are integer divisions; that is, the remainder 
is discarded leaving only the integer quotient.


History:  

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

Re: [LEAPSECS] presentations from AAS Future of Time sessions

[shin ohira]

—
Sent from Mailbox for iPhone

On Tue, Jan 7, 2014 at 3:40 AM, Rob Seaman  wrote:

> PDFs of the slides from the talks yesterday (5 Jan 2014) are now available at:
>   http://www.cacr.caltech.edu/futureofutc/aas223/
> Rob
> --
> PS -  In addition to many other links, see C. A. McDaniel Wyman's Master's 
> Thesis, "The Leap Second Debate" midway down:
>   http://www.cacr.caltech.edu/futureofutc/links.html
> ___
> 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