Leap seconds

I'd be interested to know if any developers are affected by the recently issued "leap second" in their software. These may become an issue if you record high-resolution time-based data for long periods of time (which happens to be our business).
If neither discarding the extra second nor having a duplicate time stamp in the database is acceptable, how do you handle this?
0
Arthur
7/2/2015 8:35:50 AM
📁 embarcadero.delphi.non-tech
📃 5933 articles.
⭐ 1 followers.

💬 9 Replies
👁️‍🗨️ 875 Views


Arthur Hoornweg wrote:
> I'd be interested to know if any developers are affected by the
> recently issued "leap second" in their software. These may become an
> issue if you record high-resolution time-based data for long periods
> of time (which happens to be our business).
> 
> If neither discarding the extra second nor having a duplicate time
> stamp in the database is acceptable, how do you handle this?
Why a duplicate time stamp? Why not just a single, correct time stamp?
-- 
Rudy Velthuis        http://www.rvelthuis.de
"There's a fine line between being on the leading edge and being
 in the lunatic fringe." -- Frank Armstrong
0
Rudy
7/2/2015 9:25:33 AM
Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote in news:727626
@forums.embarcadero.com:
> 
> Why a duplicate time stamp? Why not just a single, correct time stamp?
> 
Becasue the leap second means that at some point the same second occurs 
twice.
That means a small change that the same timestamp will occur.
Unless you user the frowned upon Google method of handling leap seconds of 
course.
0
Christopher
7/2/2015 9:41:44 AM
Christopher Burke wrote:
> Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote in news:727626
> @forums.embarcadero.com:
> 
> > 
> > Why a duplicate time stamp? Why not just a single, correct time
> > stamp?
> > 
> 
> Becasue the leap second means that at some point the same second
> occurs twice.
Not really, although setting the clock back one second is one way of
dealing with it.
-- 
Rudy Velthuis        http://www.rvelthuis.de
"I would have made a good Pope."
 -- Richard M. Nixon (1913-1994)
0
Rudy
7/2/2015 1:53:39 PM
Am 02.07.2015 um 15:53 schrieb Rudy Velthuis (TeamB):
> Christopher Burke wrote:
> 
>> Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote in news:727626
>> @forums.embarcadero.com:
>>
>>>
>>> Why a duplicate time stamp? Why not just a single, correct time
>>> stamp?
>>>
>>
>> Becasue the leap second means that at some point the same second
>> occurs twice.
> 
> Not really, although setting the clock back one second is one way of
> dealing with it.
> 
Hello,
I fear you haven't yet understood completely: if you record some data
every second and store that in a DB with the requirement that the
timestamp is unique you're introuble by just readjusting the clock for
that second, as this will prduce the same timestamp again.
Greetings
Markus
0
Markus
7/2/2015 7:02:01 PM
Markus Humm wrote:
> if you record some data
> every second and store that in a DB with the requirement that the
> timestamp is unique you're introuble by just readjusting the clock for
> that second, as this will prduce the same timestamp again.
Yes, this is problem.
AFAIK OSs have special mechanism to avoid time jumps: the system is
slightly lengthen/shorten the timer tick until the system time will not
be accurate; there is no time jump in this case.
But I do not know how to system handles the massive jump time jump
(like second in question). Probably system does the same but the system
time becomes inaccurate on some relatively long interval.
--
Alex
0
Alex
7/3/2015 4:37:12 AM
Markus Humm wrote:
> Am 02.07.2015 um 15:53 schrieb Rudy Velthuis (TeamB):
> > Christopher Burke wrote:
> > 
> >> Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote in
> news:727626 >> @forums.embarcadero.com:
> > > 
> > > > 
> >>> Why a duplicate time stamp? Why not just a single, correct time
> >>> stamp?
> > > > 
> > > 
> >> Becasue the leap second means that at some point the same second
> >> occurs twice.
> > 
> > Not really, although setting the clock back one second is one way of
> > dealing with it.
> > 
> 
> Hello,
> 
> I fear you haven't yet understood completely: if you record some data
> every second and store that in a DB with the requirement that the
> timestamp is unique you're introuble by just readjusting the clock for
> that second, as this will prduce the same timestamp again.
I have understood that. One way of dealing with this is a unique
timestamp for that one leap second. Of course, if that is possible
depends on who writes which part of the software.

-- 
Rudy Velthuis        http://www.rvelthuis.de
Carlson's Consolation: Nothing is ever a complete failure; it can
always serve as a bad example.
0
Rudy
7/3/2015 6:26:19 AM
> AFAIK OSs have special mechanism to avoid time jumps: the system is
> slightly lengthen/shorten the timer tick until the system time will not
> be accurate; there is no time jump in this case.
No. That's the solution that Amazon and Google implemented in their own services to "fool" OS/applications that can't handle a leap second properly, but it's not a general one. The NTP protocol does actually send a "leap second" flag, but tthen it's up to the system how to handle it.
Actually, Windows doesn't handle leap seconds truly:
https://support.microsoft.com/en-us/kb/909614
Thereby you can risk the clock being turned back one second the next time Windows Time Service syncs the time.
Linux uses a 61 second minute (but beware some older kernels have a bug), it will add a second (this is from a machine of mine that was in CEST time zone):
Jul  1 01:59:59 ntdb kernel: [662118.555111] Clock: inserting leap second 23:59:60 UTC
Thereby applications need be ready to accept a 61 second minute, and a 86401 seconds day - is the Delphi RTL designed to accept leap seconds? I never checked.
If using a database (or whatever else handling dates), you need to check how it deals with leap seconds. If you believed UTC was a solution to have unique timestamps and 86400 days always, well, you didn't understand UTC fully :-)
0
Luigi
7/3/2015 10:06:57 AM
Luigi Sandon wrote:
> If you believed UTC was a solution to have unique timestamps and 86400
> days always, well, you didn't understand UTC fully :-)
Thank you for information.
Thank God, I have no deal with precise time in my practice. :-)
--
Alex
0
Alex
7/4/2015 12:39:37 PM
Markus Humm wrote:
> Am 02.07.2015 um 15:53 schrieb Rudy Velthuis (TeamB):
> > Christopher Burke wrote:
> > 
> >> Rudy Velthuis (TeamB) <newsgroups@rvelthuis.de> wrote in
> news:727626 >> @forums.embarcadero.com:
> > > 
> > > > 
> >>> Why a duplicate time stamp? Why not just a single, correct time
> >>> stamp?
> > > > 
> > > 
> >> Becasue the leap second means that at some point the same second
> >> occurs twice.
> > 
> > Not really, although setting the clock back one second is one way of
> > dealing with it.
> > 
> 
> Hello,
> 
> I fear you haven't yet understood completely:
I think I understood much better than you fear.
> if you record some data
> every second and store that in a DB with the requirement that the
> timestamp is unique you're introuble by just readjusting the clock for
> that second, as this will prduce the same timestamp again.
Not necessarily. Make the timestamp unique.

-- 
Rudy Velthuis        http://www.rvelthuis.de
Weinberg's Corollary: An expert is a person who avoids the small
errors while sweeping on to the grand fallacy.
0
Rudy
7/5/2015 4:34:37 PM
Reply: