On 2014-02-12 01:46 PM, Warner Losh wrote:
Other systems are less open, and sweep this data under the rug is also a valid
conclusion.
There's no mystery how Windows handles Leap Seconds - it doesn't.
Its off by the Leap Second until it re-syncs to NTP.
How the Windows Time service treats a l
On 2014-02-12 03:53 PM, Richard Clark wrote:
Back in the 1974 oil crisis the US made an 'emergency' change to its
DST schedual. I don't recall the legal mechanism used. It was likely
an executive order from the President.
Is was an act of Congress - the Emergency Daylight Saving Time Energy
Con
Warner Losh writes:
>
> On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:
> > The conclusions I draw from the utter lack of any similar reports from
> > non-linux systems are:
> >
> > - either those kernels/libraries did not do leap-second processing, or
> > - they did and their code worked
> >
>
Back in the 1974 oil crisis the US made an 'emergency' change to its
DST schedual. I don't recall the legal mechanism used. It was likely
an executive order from the President.
But it most definitely was with less than 6 months notice so the legal
precedent is exists in the US.
I also have notic
Brooks Harris said:
> D) Clarifying timezone guidelines, including standardizing
> "international date line", "UTC offset", and methods of "Daylight
> instantiation"
Um, timezones are a political matter pure and simple. Who do you think is
going to listen to you?
--
Clive D.W. Feather
Hal Murray said:
> I don't pay attention to summer time in Europe. How often do things change
> over there and/or how much notice do people get when the rules are changed?
The EU has standard rules defined in a Directive. The present Directive is
2000/84/EC and was published in the Official Jour
Warner Losh said:
>> Yes. I've never been able to understand why facing the guts of this problem
>> has been evaded. Its a great computer-science project - it should be fun!
>
> The problem stems not because one person can't climb the complexity hill to
> get it right: several have. The problem
On Feb 12, 2014, at 1:50 PM, Harlan Stenn wrote:
> The conclusions I draw from the utter lack of any similar reports from
> non-linux systems are:
>
> - either those kernels/libraries did not do leap-second processing, or
> - they did and their code worked
>
> Do you have different conclusions?
Warner Losh writes:
>
> On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote:
>
>> Warner Losh writes:
>>>
>>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>>>
>> Um, that is false. All linux kernels did not crash, in fact NONE of
>> mine did.
>
> "all" here was an overst
> E) Leap seconds are tied to observations of the earth's spin, rather than
> predicted years in advance. With only 6 months warning for leap seconds,
> this produces operational difficulties for many environments that have
> burdensome change control policies.
What do those organizations do when
On Feb 12, 2014, at 11:22 AM, Rob Seaman wrote:
> Hi Warner,
>
> You’ll note that this particular email is addressed to you. Most
> contributions to this mailing list are not personally addressed. In those
> cases one might reasonably infer that other messages were intended as general
> con
On 2014-02-12 09:46 AM, Warner Losh wrote:
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote:
On 2014-02-12 08:09 AM, Rob Seaman wrote:
There are many much more complex computer science challenges. In fact, the
entire purpose of these things called computers is to deal efficiently with
hella
Hi Warner,
You’ll note that this particular email is addressed to you. Most contributions
to this mailing list are not personally addressed. In those cases one might
reasonably infer that other messages were intended as general contributions to
a common forum.
> On Feb 12, 2014, at 9:09 AM,
On Feb 12, 2014, at 9:54 AM, Brooks Harris wrote:
> On 2014-02-12 08:09 AM, Rob Seaman wrote:
>>
>> There are many much more complex computer science challenges. In fact, the
>> entire purpose of these things called computers is to deal efficiently with
>> hellaciously complicated problems.
On 2014-02-12 08:03 AM, Warner Losh wrote:
On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote:
On 2014-02-12 04:36 AM, Greg Hennessy wrote:
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should nev
On 2014-02-12 08:09 AM, Rob Seaman wrote:
There are many much more complex computer science challenges. In fact, the
entire purpose of these things called computers is to deal efficiently with
hellaciously complicated problems. This problem ain't that intractable.
Yes. I've never been able
On 2014-02-12 07:47 AM, Warner Losh wrote:
The linux kernel has been touted by some of its proponents as the most tested
and verified kernel around. Some may quibble with this characterization, but if
not the most, certainly one of the most. And even so, this problem with leap
seconds managed
On Feb 12, 2014, at 9:09 AM, Rob Seaman wrote:
> On Feb 12, 2014, at 8:47 AM, Warner Losh wrote:
>
>> The linux kernel has been touted by some of its proponents as the most
>> tested and verified kernel around. Some may quibble with this
>> characterization, but if not the most, certainly one
On Feb 12, 2014, at 8:47 AM, Warner Losh wrote:
> The linux kernel has been touted by some of its proponents as the most tested
> and verified kernel around. Some may quibble with this characterization, but
> if not the most, certainly one of the most. And even so, this problem with
> leap sec
On Feb 12, 2014, at 8:03 AM, Brooks Harris wrote:
> On 2014-02-12 04:36 AM, Greg Hennessy wrote:
>>
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
>>>
>>> "all" here was an overstatement, but the impact of the leap second
>>> should never be "your kernel
On Feb 12, 2014, at 7:53 AM, Harlan Stenn wrote:
> Warner Losh writes:
>>
>> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>>
>>>
> Um, that is false. All linux kernels did not crash, in fact NONE of
> mine did.
"all" here was an overstatement, but the impact of the leap
Warner Losh writes:
>
> On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>
> >
> >>> Um, that is false. All linux kernels did not crash, in fact NONE of
> >>> mine did.
> >>
> >> "all" here was an overstatement, but the impact of the leap second
> >> should never be "your kernel crashes" even
On 2014-02-12 04:36 AM, Greg Hennessy wrote:
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should never be "your kernel crashes" even if your personal kernels
didn't.
You should refrain from m
On Feb 12, 2014, at 5:36 AM, Greg Hennessy wrote:
>
>>> Um, that is false. All linux kernels did not crash, in fact NONE of
>>> mine did.
>>
>> "all" here was an overstatement, but the impact of the leap second
>> should never be "your kernel crashes" even if your personal kernels
>> didn't.
>
Um, that is false. All linux kernels did not crash, in fact NONE of
mine did.
"all" here was an overstatement, but the impact of the leap second
should never be "your kernel crashes" even if your personal kernels
didn't.
You should refrain from making inaccurate claims, it damages your
credi
On Feb 11, 2014, at 5:34 PM, Greg Hennessy wrote:
>> People have been working for the past 15 years to make leap seconds
>> better, yet in the last leap second all Linux kernels crashed due to
>> a subtle bug that is only triggered when there was a leap second.
>
> Um, that is false. All linux ke
The effects of those leap seconds are a clear and present danger.
Some people claim this. Others disagree.
People have been working for the past 15 years to make leap seconds
better, yet in the last leap second all Linux kernels crashed due to
a subtle bug that is only triggered when there was
> >> People have been working for the past 15 years to make leap seconds
> >> better, yet in the last leap second all Linux kernels crashed due
> >> to a subtle bug that is only triggered when there was a leap second.
> >My understanding wasn't that all Linux kernels crashed.
> Only the ones whic
On Feb 11, 2014, at 11:22 AM, Tim Shepard wrote:
>
>
People have been working for the past 15 years to make leap seconds
better, yet in the last leap second all Linux kernels crashed due
to a subtle bug that is only triggered when there was a leap second.
>>>
>>> My understandin
> >> People have been working for the past 15 years to make leap seconds
> >> better, yet in the last leap second all Linux kernels crashed due
> >> to a subtle bug that is only triggered when there was a leap second.
> >
> >My understanding wasn't that all Linux kernels crashed.
>
> Only the on
On Feb 11, 2014, at 10:12 AM, Rob Seaman wrote:
> Your definition of the word “cope” is different than mine. It would be a
> trivial change to permit leap seconds more frequently than monthly. Such
> won’t be needed for many centuries. Leap hours are an impractical rhetorical
> gimmick to du
On Feb 11, 2014, at 10:27 AM, Poul-Henning Kamp wrote:
> In message <20140211171627.ga73...@walton.maths.tcd.ie>, David Malone writes:
>>> People have been working for the past 15 years to make leap seconds
>>> better, yet in the last leap second all Linux kernels crashed due
>>> to a subtle bug
In message <20140211171627.ga73...@walton.maths.tcd.ie>, David Malone writes:
>> People have been working for the past 15 years to make leap seconds
>> better, yet in the last leap second all Linux kernels crashed due
>> to a subtle bug that is only triggered when there was a leap second.
>
>My und
> People have been working for the past 15 years to make leap seconds
> better, yet in the last leap second all Linux kernels crashed due
> to a subtle bug that is only triggered when there was a leap second.
My understanding wasn't that all Linux kernels crashed. I though
some fraction of the ker
Your definition of the word “cope” is different than mine. It would be a
trivial change to permit leap seconds more frequently than monthly. Such won’t
be needed for many centuries. Leap hours are an impractical rhetorical gimmick
to dump the whole question (except the significant costs to ma
Rob Seaman wrote:
> On Feb 11, 2014, at 9:31 AM, Tony Finch wrote:
> >
> > Yes. And time zone adjustments will be able to keep civil time in sync
> > with earth rotation for a much longer time than leap seconds :-)
>
> Nonsense!
Leap seconds can deal with a rate difference of at most 12s per yea
On Feb 11, 2014, at 9:31 AM, Tony Finch wrote:
> Warner Losh wrote:
>>
>> Perhaps, but leap seconds are a solution to the problem that must die in
>> the fullness of time. With the quadratic acceleration there will come a
>> time in a few thousand years when one leap second a month or day isn't
On Feb 11, 2014, at 9:46 AM, Rob Seaman wrote:
> On Feb 11, 2014, at 9:31 AM, Tony Finch wrote:
>
>> Warner Losh wrote:
>>>
>>> Perhaps, but leap seconds are a solution to the problem that must die in
>>> the fullness of time. With the quadratic acceleration there will come a
>>> time in a fe
Warner Losh wrote:
>
> Perhaps, but leap seconds are a solution to the problem that must die in
> the fullness of time. With the quadratic acceleration there will come a
> time in a few thousand years when one leap second a month or day isn't
> enough and another solution will be necessary to keep
On Feb 10, 2014, at 5:49 PM, Greg Hennessy wrote:
> On 02/10/2014 11:57 AM, Warner Losh wrote:
>
>> I get that people don't like this, and that there's some resistance
>> to it on aesthetic grounds dressed up in the guise of technical
>> arguments about universal not meaning what it has always m
The problem with adding an hour is when and where it is added. If the
hour was added at the midnight at the prime meridian, it would be
disruptive to rush hour and work schedules for most of the world's
population. A critical difference between the management of UTC and the
management of time zon
On 02/10/2014 11:57 AM, Warner Losh wrote:
I get that people don't like this, and that there's some resistance
to it on aesthetic grounds dressed up in the guise of technical
arguments about universal not meaning what it has always meant, and
that entrenched interests aren't unhappy enough with
On Feb 10, 2014, at 4:24 PM, Rob Seaman wrote:
> On Feb 10, 2014, at 9:57 AM, Warner Losh wrote:
>
>> On Feb 10, 2014, at 9:02 AM, Rob Seaman wrote:
>>
>>> Like I said, it is an attempt to confuse two different concepts.
>>
>> We disagree here then. Atomic time is adequate for civil needs. Th
On Feb 10, 2014, at 9:57 AM, Warner Losh wrote:
> On Feb 10, 2014, at 9:02 AM, Rob Seaman wrote:
>
>> Like I said, it is an attempt to confuse two different concepts.
>
> We disagree here then. Atomic time is adequate for civil needs. The small
> divergence can be handled the same way we handl
On Feb 10, 2014, at 9:02 AM, Rob Seaman wrote:
> On Feb 9, 2014, at 11:20 AM, Warner Losh wrote:
>
>> On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote:
>>> If anything has prevented leap seconds from death it is the weakness of the
>>> proposal itself. And the real-world distinction between Univ
On Feb 9, 2014, at 11:20 AM, Warner Losh wrote:
> On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote:
>> If anything has prevented leap seconds from death it is the weakness of the
>> proposal itself. And the real-world distinction between Universal Time and
>> Atomic Time; "Death to leap seconds!"
On Feb 9, 2014, at 11:13 AM, Rob Seaman wrote:
>
> If anything has prevented leap seconds from death it is the weakness of the
> proposal itself. And the real-world distinction between Universal Time and
> Atomic Time; "Death to leap seconds!" is the rallying cry of somebody who
> wants to pr
On Feb 8, 2014, at 5:11 PM, Brooks Harris wrote:
> On 2014-02-07 04:12 AM, Poul-Henning Kamp wrote:
>> In message <20140206151947.ga25...@ucolick.org>, Steve Allen writes:
>>
>>> Taken at face value Google's Site Reliability Team would seem to be
>>> arguing for the return to the bad old days of
On 2014-02-07 04:12 AM, Poul-Henning Kamp wrote:
In message <20140206151947.ga25...@ucolick.org>, Steve Allen writes:
Taken at face value Google's Site Reliability Team would seem to be
arguing for the return to the bad old days of the rubber second.
Yeah, they're totally opposed to having equ
In message <20140206151947.ga25...@ucolick.org>, Steve Allen writes:
>Taken at face value Google's Site Reliability Team would seem to be
>arguing for the return to the bad old days of the rubber second.
Yeah, they're totally opposed to having equal-length seconds, and they
really showing the wor
On 6 Feb 2014, at 17:16, Michael Spacefalcon wrote:
> Steve Allen wrote:
>
>> Taken at face value Google's Site Reliability Team would seem to be
>> arguing for the return to the bad old days of the rubber second.
>> It's hard to believe that Google's Android and driverless car divisions
>> ho
Steve Allen wrote:
> Taken at face value Google's Site Reliability Team would seem to be
> arguing for the return to the bad old days of the rubber second.
> It's hard to believe that Google's Android and driverless car divisions
> hold the same position, but they haven't spoken.
Why can't that
Ian Batten wrote:
>
> All the coverage again points out that the "Greenwich" time signal is in fact
> a melange of
> UTC(GPS), UTC(NPL) and the BBC's own atomic clocks, rather than GMT (ie UT1).
> Another indicator that although UK legal time is UT1, in practice not only
> does everyone use UTC,
On Thu 2014-02-06T11:32:09 +, Ian Batten hath writ:
> All the coverage again points out that the "Greenwich" time signal is in fact
> a melange of
> UTC(GPS), UTC(NPL) and the BBC's own atomic clocks, rather than GMT (ie UT1).
> Another indicator that although UK legal time is UT1, in practice
On 5 Feb 2014, at 23:50, Richard Clark wrote:
> I'm surprised that someone on the list hasn't already pointed this out.
>
> Today February 5 2014 (already yesterday in much of the world) marks
> the 90th anniversary of the BBC's time pips as we know them.
All the coverage again points out that
I could have sworn that was Nye v Ham, not the State of the Union…
On Feb 5, 2014, at 4:50 PM, Richard Clark wrote:
> I'm surprised that someone on the list hasn't already pointed this out.
>
> Today February 5 2014 (already yesterday in much of the world) marks
> the 90th anniversary of the BB
I'm surprised that someone on the list hasn't already pointed this out.
Today February 5 2014 (already yesterday in much of the world) marks
the 90th anniversary of the BBC's time pips as we know them.
I had been thinking about broadcast time signals recently. Here in the
USA we just experienced
57 matches
Mail list logo
