On Mon, Jul 25, 2016 at 7:56 AM, Martin Burnicki
wrote:
> Tony Finch wrote:
>> Martin Burnicki wrote:
>>>
>>> IMO a better approach would be to let the system time run on TAI, and do
>>> the conversion to UTC, and local time in the next step, by runtime
>>> libraries.
>>
>> The kernel needs to kn
Tony Finch wrote:
> Martin Burnicki wrote:
>>
>> IMO a better approach would be to let the system time run on TAI, and do
>> the conversion to UTC, and local time in the next step, by runtime
>> libraries.
>
> The kernel needs to know UTC for things like filesystem timestamps.
I know. This is ma
Tom Van Baak said:
>> Does your proposal allow for a Zero leap second
> Nope, LSEM avoids the zero leap second situation. That's the idea: to always
> have a leap second. Either an add or a delete, at the end of every month. The
> beauty is that it wouldn't violate how UTC is already defined. Lea
Tom Van Baak wrote:
>
> > Does your proposal allow for a Zero leap second
>
> Nope, LSEM avoids the zero leap second situation. That's the idea: to
> always have a leap second. Either an add or a delete, at the end of
> every month. The beauty is that it wouldn't violate how UTC is already
> defin
Martin Burnicki wrote:
>
> IMO a better approach would be to let the system time run on TAI, and do
> the conversion to UTC, and local time in the next step, by runtime
> libraries.
The kernel needs to know UTC for things like filesystem timestamps.
Tony.
--
f.anthony.n.finchhttp://dotat.at
On 21 July 2016 at 23:49, Hal Murray wrote:
> Has anybody done any serious thinking about fixing the POSIX problem?
My hope when I defined the Java time-scale [1] was that eventually the
OS would provide it, or something very similar.
The basic observation that I have had over many years is that
Hal Murray wrote:
>
> s...@ucolick.org said:
>> This idea pushes extra complexity into every implementation of low level
>> kernel-space software, firmware, and hardware. That's nice as a policy for
>> full employment of programmers, but it's hard to justify by any other
>> metric. Instead those
Tom Van Baak wrote:
> Time to mention this again...
>
> If we adopted the LSEM (Leap Second Every Month) model then none of
> this would be a problem. The idea is not to decide *if* there will be
> leap second, but to force every month to have a leap second. The IERS
> decision is then what the *s
s...@ucolick.org said:
> This idea pushes extra complexity into every implementation of low level
> kernel-space software, firmware, and hardware. That's nice as a policy for
> full employment of programmers, but it's hard to justify by any other
> metric. Instead those low level places should b
Hi Tom,
> Does your proposal allow for a Zero leap second
Nope, LSEM avoids the zero leap second situation. That's the idea: to always
have a leap second. Either an add or a delete, at the end of every month. The
beauty is that it wouldn't violate how UTC is already defined. Leap seconds
would
Steve Allen wrote:
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware. That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric. Instead those low level places should be as
On Thu 2016-07-21T10:27:57 -0700, Tom Van Baak hath writ:
> Time to mention this again...
> Every UTC-aware device would 1) know how to reliably insert or
> delete a leap second, because bugs would be found by developers within
> a month or two, not by end-users years or decades in the future, and
Hi Tom,
This message is an excellent example of why we invited you to speak at the
Science of Time symposium ;-)
It was a shame you couldn’t make it, since you would have made an excellent
meeting even stronger. But future meetings in the series seem very likely and
let me register an invitati
Time to mention this again...
If we adopted the LSEM (Leap Second Every Month) model then none of this would
be a problem. The idea is not to decide *if* there will be leap second, but to
force every month to have a leap second. The IERS decision is then what the
*sign* of the leap second shoul
Warner Losh wrote:
> On Wed, Jul 20, 2016 at 9:27 AM, Martin Burnicki
> wrote:
>> Each bulletin C from IERS says:
>>
>> "Leap seconds can be introduced in UTC at the end of the months of
>> December or June, depending on the evolution of UT1-TAI. Bulletin C is
>> mailed every six months, either t
Hi Warner,
On 2016-07-20 11:34 AM, Warner Losh wrote:
On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris wrote:
Hi Tom,
A couple questions and thoughts concerning standards and nomenclature -
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
Hi Mark,
Three comments:
1)
I recall this is a known prob
On Wed 2016-07-20T09:34:47 -0600, Warner Losh hath writ:
> I seem to recall finding a really old version of TF.460 that didn't have the
> minimum time.
http://www.ucolick.org/~sla/leapsecs/timescales.html#1972
This URI targets the inception of leap seconds, but the surrounding
entries from 1969 t
On 2016-07-20 11:27 AM, Martin Burnicki wrote:
Brooks Harris wrote:
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
I recall this is a known problem in the Z3801A status reporting, and
possibly other GPS receivers of that era as well. It stems indirectly
from a change years ago in how far in advanc
On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris wrote:
> Hi Tom,
>
> A couple questions and thoughts concerning standards and nomenclature -
>
> On 2016-07-20 01:08 AM, Tom Van Baak wrote:
>>
>> Hi Mark,
>>
>> Three comments:
>>
>> 1)
>> I recall this is a known problem in the Z3801A status reporti
On Wed, Jul 20, 2016 at 9:27 AM, Martin Burnicki
wrote:
> Brooks Harris wrote:
>> On 2016-07-20 01:08 AM, Tom Van Baak wrote:
>>> I recall this is a known problem in the Z3801A status reporting, and
>>> possibly other GPS receivers of that era as well. It stems indirectly
>>> from a change years a
Brooks Harris wrote:
> On 2016-07-20 01:08 AM, Tom Van Baak wrote:
>> I recall this is a known problem in the Z3801A status reporting, and
>> possibly other GPS receivers of that era as well. It stems indirectly
>> from a change years ago in how far in advance IERS and DoD were able
>> to update th
Hi Tom,
A couple questions and thoughts concerning standards and nomenclature -
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
Hi Mark,
Three comments:
1)
I recall this is a known problem in the Z3801A status reporting, and possibly
other GPS receivers of that era as well. It stems indirectly f
Hi Mark,
Three comments:
1)
I recall this is a known problem in the Z3801A status reporting, and possibly
other GPS receivers of that era as well. It stems indirectly from a change
years ago in how far in advance IERS and DoD were able to update the leap
second info into the GPS constellation.
23 matches
Mail list logo
