> 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. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
