Tony Finch wrote:
> And I seem to remember from reading the materials that they also ignored
> the cultural damage that was done by the introduction of leap seconds in
> the first place, breaking a multi-thousand-year tradition of base 60
> fractions, making all mechanical clocks obsolete, and so
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
Warner Losh wrote:
> Also, these systems were not on the internet, so downloading one of the many
> sources of TAI-UTC differences wasn't an option.
OK, obviously asking every system to be connected to the Internet
would be a non-starter, for security etc reasons, but what's wrong
with dedicated
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 b
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 Lea
Joseph Gwinn wrote:
> Well, yes, but I guess it's a bit of hair splitting. The UNIX docs may
> well still say GMT, but I bet what they really use is UTC, as that's
> what's distributed.
Using UTC as a *realisation* of GMT is acceptable only for as long as
UTC remains a *good faith* approximat
Joseph Gwinn wrote:
> In the UNIX before POSIX, it was GMT.
Your use of the past tense is incorrect. In non-POSIX UNIX, it (the
system time definition) *is* GMT, present tense. See my previous
post.
VLR,
SF
___
LEAPSECS mailing list
LEAPSECS@leapsec
e 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 im
mc235960 wrote:
> I wonder if the author did his sums before putting pen to paper.
> The Lorekeeper, Fin Lerisas implies that there are -ve leap hours every year.
I don't think that's what the author meant - instead he (the author)
is simply making a mockery of a different form of time violation
Daniel R. Tobias wrote:
> Actually, from what I've seen and heard about this year's crop of
> bugs, server crashes, etc., relating to the leap second, the big
> problems come when the developers know and care just enough to be
> dangerous.
Yup.
> If you take the total dumbass approach to lea
Dennis Ferguson wrote:
> A very long time ago (more than a quarter century) BSD Unix kernels
> had code in the kernel's time-reading logic which would record the
> time returned each time the clock was read, and which would ensure
> that a subsequent call to get the time would return a time at le
Poul-Henning Kamp wrote:
> Yes +/- 4 hours or so.
Only for you and those of your ilk. For me the tolerance is much,
much tighter:
* The long-term measure of days must agree with the true evolution of
mean solar time (longitude-independent) to within 1 s.
* Using the mean solar time at a sta
Warner Losh wrote:
> 4 is used to paper over the leap second, but the number of stupid apps out
> there is quite large,
Not stupid, but designed for GMT rather than UTC. GMT doesn't have
leap seconds, it is scalar (real number, not broken down struct),
continuous and monotonically increasing, b
Rob Seaman wrote:
> Sealand is about an 1/8th of an acre. A speed limit is fairly moot.
My point was that speed limit laws of any kind are bad, countries that
make such laws are bad countries, and we, the technical vanguard
people of the World, should not be giving any technical assistance to
t
undergoes a deleterious redefinition, I'll have to scramble to
build my rubber duckie apparatus that would generate my proposed
alternate UTR time scale.
Gerard Ashton wrote:
> Michael Spacefalcon gave an overview of how a high precision system (which
> he incorrectly supposed I posses
Gerard Ashton wrote:
> Michael Spacefalcon wrote " a standardized, widely recognized and adopted
> scheme for converting leap seconds to rubber seconds is what we need"
> but also mentioned "a normal computer motherboard quartz crystal
> oscillator". But of cours
Warner Losh wrote:
> I think this was more of a comment about how fragile our modern
> infrastructure is when confronted with a Leap Second.
Yes, I agree that the evidence points in the direction of your
statement. But we probably disagree on what the right solution is.
Per my religion, Leap Se
Carlos Alberto Lopez Perez wrote:
> Computers are not designed to cope with random time drifts,
Mine are. Please don't make blanket statements.
--
Michael Spacefalcon,
formerly Michael Sokolov,
who uses rubber seconds and has just recently
gone through the system documentation, cha
18 matches
Mail list logo
