[LEAPSECS] Coming of age in the solar system

Paul Sheer p at 2038bug.com
Sat Sep 4 17:05:26 EDT 2010




> And because your code is time-agnostic, you are 100% sure that no

> telco anywhere has any leap-second issues with any code they run

> in their system ?

>


No, just 99% sure.

But here is an anecdote: It's standard practice when writing
business software to use "SELECT time('now')" and not gettimeofday()
to get the time. This is because you want the time to come from
one source (the database); otherwise you could have inconsistent
data entered into your tables - a situation you can't repair.

It's almost as fundamental a principle as ACID.

Databases have extremely sophisticated time handling functions.
It's a "solved problem" and it's not a space you ever want to
try compete in.



> Do I need to remind you about the 3rd rule of software development:

>

> 3. The only thing worse than generalizing from one example

> is generalizing from no examples at all.

>


how about generalizing from two examples as you have given :-)



> No, I said exactly what I said: Very few of the leap second

> induced anomalies gets recognized for what they are, fewer still

> gets reported as such and since nobody thinks there is anything

> that can be done about it, the reports gather dust.

>


but you know about these reports because... you are psychic?



> To that I can add, that a lot of organizations have special

> operational status across leap-seconds. Basically they give

> up trying to handle it correctly, and simply shut down/idle

> their operation in a window around the leap second.

>

> One example: Medicine production.

>

> FDA and EU requires lot-tracking to the second. It is cheaper to

> not transfer any substances for a window of N minutes around the

> leap second, thus avoiding any timestamps during the leapsecond,

> than it is to qualify that all kit will do the leap second correctly.


sounds like UTC-SLS solves this problem - no?



>

> I know several facilities of various kinds I which schedule their

> yearly maintenance during leap-seconds, or shut down extraordinarily.

>


let's discuss these then. URL please?


-paul








More information about the LEAPSECS mailing list