[LEAPSECS] ] Fractional US civil time period representation is brittle

Hal Murray 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
time commands.

-----------

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 mailing list