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

[Hal Murray]

> 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.