On Sun, Jul 1, 2012 at 11:15 UTC, AlbyVA wrote: > > It looks like my server picked up the Leap Second, but it just counted > 19:59:59 twice. > Check it out: (NOTE: EDT -0400 Timezone). > > Sat, Jun 30 2012 19:59:59.387 > Sat, Jun 30 2012 19:59:59.894 > Sat, Jun 30 2012 19:59:59.401 > Sat, Jun 30 2012 19:59:59.907 > Sat, Jun 30 2012 20:00:00.656 > Sat, Jun 30 2012 20:00:01.170 > Sat, Jun 30 2012 20:00:01.677
That looks perfect, or at least the best you're going to get without extra homework. If you were expecting to see it count through 19:59:60 and disappointed, there is no consolation prize other than the knowledge it would be impossible. Computer clocks don't actually keep date and time as distinct fields like minute and second, but rather as a simple number counting units of time since some "epoch" date in the past. Displaying the clock to the user in a gregorian calendar and 24-hour clock form requires converting the epoch-based clock number, such as POSIX time_t's seconds-since-1970, on the assumption that every day has 24 hours of 60 minutes of 60 seconds. Such conversion by definition always results in a seconds value >= 0 and < 60. Your OS may log a message about inserting leap second 19:59:60, if so, it likely steps the clock backward 1 second at midnight UTC, which is equivalent to 23:59:59 occurring twice. The fact that some software assumes clocks move only in the normal direction is not news. People have tended to mention databases, but any software that accesses a clock or timestamps saved earlier from a clock may suffer the same fragility. Systems with good clock synchronization are at a disadvantage here, in the sense that most software on them simply never sees a backward clock step in normal operation, and may never have been tested, or have evolved since it was last tested. Cheers, Dave Hart _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
