[LEAPSECS] ] Fractional US civil time period representation is brittle
hmurray at megapathdsl.net
Mon Jan 23 04:24:25 EST 2012
> Notice that I have not specified that the actual syscall must use FP, the
> conversion from 64.64 to FP could, and probably should, happen in libc.
That means somebody could implement this now with current POSIX kernel
support and see how well it works.
> My proposed API does not solve all imaginable problems relating to time, in
> particular it does not solve the "programmer is clueless about time"
> problem, but it does try to make it easier for programmers to do things
> right, than for them to make mistakes.
I think it would be a big help if the documentation had a section describing
the not-so-obvious parts of time. Are they all associated with leap seconds?
How about leap years? (a year from today gets interesting)
Perhaps it should go in a separate man page listed in the SEE ALSO pages of
Has anybody made a list of routines that take time as a parameter?
sleep, usleep, select...
>>Testing for equality of timestamps?
> I would hope that using a FP format and mandate that for runtime you never
> get two which are the same, should eliminate that hobby.
They might be equal if generated on two different systems.
Even if we only have one system, I'm not sure I want a simple concept like
get-the-current-time to require a lock on multicpu or multicore systems.
> You can create any UTC timestamp you want at any point in history where it
> is defined.
> But you can only convert that UTC timestamp to a realtime_t (and vice-versa)
> for timestamps where the conversion is defined.
> UTC is only defined approximately 6 months in advance, and that is an
> interesting point for implementors of this API.
I think a useful system needs a way to say "a year from now", or next Dec 25.
> One of the problems right now with the 'right' database is that you have to
> update it and already running programs don't notice this update since it
> would be prohibitively expensive to do a stat call on each time operation.
> Any clever ideas around this issue?
2 suggestions (we can debate the clever part):
Poll once per day.
Kick the program with a signal similar to what happens when log files get
rotated, or piggyback on the same signal.
These are my opinions, not necessarily my employer's. I hate spam.
More information about the LEAPSECS