info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Leap second could cause problems for stock market, corporate regulator warns
15 views
Skip to first unread message
Sylvia Else
May 20, 2015, 10:08:57 PM5/20/15
to
<http://www.abc.net.au/news/2015-05-21/warning-issued-over-addition-of-leap-second-to-worlds-clocks/6485976>
Mind you, since this isn't the first leap second, it's far from clear
that there should be any new problems, except for organisations that
have implemented new time sensitive applications without attending to
the leap-second issue. If that costs them money, then it serves them right.
The Qantas glitch last time was caused by an obscure race in the Linux
kernel, now fixed, and Qantas were unlucky to have been caught by it.
As for abandoning leap seconds, that's all very well. We could tolerate
a 3 minute offset in 2100, but sometime thereafter people would have to
deal with a significant adjustment if the offset wasn't to become
unreasonably large. It would be typical example of leaving a problem for
our descendants to deal with, rather than addressing it now.
Sylvia.
Mind you, since this isn't the first leap second, it's far from clear
that there should be any new problems, except for organisations that
have implemented new time sensitive applications without attending to
the leap-second issue. If that costs them money, then it serves them right.
The Qantas glitch last time was caused by an obscure race in the Linux
kernel, now fixed, and Qantas were unlucky to have been caught by it.
As for abandoning leap seconds, that's all very well. We could tolerate
a 3 minute offset in 2100, but sometime thereafter people would have to
deal with a significant adjustment if the offset wasn't to become
unreasonably large. It would be typical example of leaving a problem for
our descendants to deal with, rather than addressing it now.
Sylvia.
Message has been deleted
Sylvia Else
May 20, 2015, 11:44:11 PM5/20/15
to
On 21/05/2015 12:25 PM, Stefan Ram wrote:
> includes leap seconds in the correct manner, because they
> believe that such an API is too difficult for programmers.
> Instead they use a fictitious calendar that does not contain
> leap seconds. So the API is kind of "broken by design".
> However, there are third-party libraries available for Java
> that account for leap seconds (such as Time4J).
>
It appears to me that Time4J also ignores leap seconds.
What constitutes the correct manned for inclusion rather depends on the
specification of your time manipulation functions. For the vast majority
of purposes, leap seconds are an irrelevance.
Sylvia.
> Sylvia Else <syl...@not.at.this.address> writes:
>> As for abandoning leap seconds, that's all very well. We could tolerate
>> a 3 minute offset in 2100, but sometime thereafter people would have to
>> deal with a significant adjustment if the offset wasn't to become
>> unreasonably large. It would be typical example of leaving a problem for
>> our descendants to deal with, rather than addressing it now.
>
> AFAIK, Oracle refuses to deliver libraries with Java that
>> As for abandoning leap seconds, that's all very well. We could tolerate
>> a 3 minute offset in 2100, but sometime thereafter people would have to
>> deal with a significant adjustment if the offset wasn't to become
>> unreasonably large. It would be typical example of leaving a problem for
>> our descendants to deal with, rather than addressing it now.
>
> includes leap seconds in the correct manner, because they
> believe that such an API is too difficult for programmers.
> Instead they use a fictitious calendar that does not contain
> leap seconds. So the API is kind of "broken by design".
> However, there are third-party libraries available for Java
> that account for leap seconds (such as Time4J).
>
It appears to me that Time4J also ignores leap seconds.
What constitutes the correct manned for inclusion rather depends on the
specification of your time manipulation functions. For the vast majority
of purposes, leap seconds are an irrelevance.
Sylvia.
Whiskers
May 21, 2015, 9:51:04 AM5/21/15
to
speculators on the world's stock markets it can matter a great deal who
issued which order first - timing transactions in nanoseconds is normal
and even that may not be precise enough for much longer. This is part
of the reason for stock market traders to continue to congregate in
particular places; the 'lag' and 'speed' of an internet connection may
be critical in some transactions.
Anything that introduces a potential error or dispute about the exact
timing of an 'order' is worth avoiding. In the case of electronic stock
markets, using a time standard that doesn't have any 'leap seconds'
would seem sensible.
<http://www.stjarnhimlen.se/comp/time.html> "Time Scales: UT1, UTC, TAI,
ET, TT, GPS time"
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Marko Rauhamaa
May 21, 2015, 1:34:39 PM5/21/15
to
Sylvia Else <syl...@not.at.this.address>:
> As for abandoning leap seconds, that's all very well. We could
> tolerate a 3 minute offset in 2100,
I don't think we're talking even about a full minute by 2100.
Besides, who cares? We can live with the Zodiac being off by a month. I
live 15 minutes behind Finland's standard time zone meridian (and
currently 45 minutes ahead of it because of DST). The technical risks
involved with capricious leap seconds are a far worse problem than the
noon being slighly off.
I'm saying, let's wait for the leap seconds to reach a full hour before
making changes to the time of day. That would give as maybe 10,000 years
to be prepared for the change.
Marko
> As for abandoning leap seconds, that's all very well. We could
> tolerate a 3 minute offset in 2100,
Besides, who cares? We can live with the Zodiac being off by a month. I
live 15 minutes behind Finland's standard time zone meridian (and
currently 45 minutes ahead of it because of DST). The technical risks
involved with capricious leap seconds are a far worse problem than the
noon being slighly off.
I'm saying, let's wait for the leap seconds to reach a full hour before
making changes to the time of day. That would give as maybe 10,000 years
to be prepared for the change.
Marko
Message has been deleted
Richard Kettlewell
May 21, 2015, 5:12:10 PM5/21/15
to
DST shift[1]. You’ll spend the next few millennia with your local clock
getting gradually more accurate (in the sense that midnight on your
clock will start to approach solar midnight instead of drifting away).
[1] Of course any given locale might not have DST at that point, in
which case a one-off adjustment would be required. But my basic
point is that the timezone system is already the right shape to
deal with the issue.
AFAIK some people (astronomers, I thik) really do care about UTC
midnight matching solar midnight at the meridian. But that’s fine: they
can maintain their own offset clocks if they like, and leave the rest of
us in peace.
--
http://www.greenend.org.uk/rjk/
Sylvia Else
May 22, 2015, 11:15:39 PM5/22/15
to
On 22/05/2015 3:34 AM, Marko Rauhamaa wrote:
> I'm saying, let's wait for the leap seconds to reach a full hour before
> making changes to the time of day. That would give as maybe 10,000 years
> to be prepared for the change.
Which is still not long enough, because the decision will be political.
> I'm saying, let's wait for the leap seconds to reach a full hour before
> making changes to the time of day. That would give as maybe 10,000 years
> to be prepared for the change.
Of course, we may have world government by then, or alternatively, no
longer have a civilisation to speak of.
Sylvia.
Richard Kettlewell
May 23, 2015, 7:24:15 AM5/23/15
to
already prepared: it happens twice a year every year in many countries,
and states tinker with the rules at the drop of a hat.
--
http://www.greenend.org.uk/rjk/
Kees Nuyt
May 23, 2015, 7:39:46 AM5/23/15
to
On Sat, 23 May 2015 12:24:15 +0100, Richard Kettlewell
<r...@greenend.org.uk> wrote:
> When we’re talking about hour-resolution changes to clocks, we’re
> already prepared: it happens twice a year every year in many countries,
> and states tinker with the rules at the drop of a hat.
Yes, but that is relatively harmless. The time itself (UTC/GMT)
<r...@greenend.org.uk> wrote:
> When we’re talking about hour-resolution changes to clocks, we’re
> already prepared: it happens twice a year every year in many countries,
> and states tinker with the rules at the drop of a hat.
doesn't change, just the presentation does.
Every decent computer/operating system/database/application keeps
time in UTC and the user interface offers a presentation in the
preferred timezone of the user.
However, leap seconds do change UTC.
In most cases that's not a real problem with NTP
timesynchronization, which guarantees that a clock never
decrements after it has been initialized.
It will just temporarily slow down the clock a bit.
--
Kees Nuyt
Richard Kettlewell
May 23, 2015, 8:40:04 AM5/23/15
to
mhoch...@gmx.de
May 27, 2015, 9:38:48 AM5/27/15
to
About your original question: I have once given following answer to similar hypes and fears around the next coming leap second and think that some people simply worry too much: http://stackoverflow.com/questions/27911432/calendar-manipulation-running-on-amazon-linux-ami-during-june-30-2015-leap-seco
Sylvia Else
May 27, 2015, 10:29:36 PM5/27/15
to
Sylvia.
0 new messages