In message <[email protected]>, "Daniel R. Tobias" writes: >On 22 Jan 2012 at 0:09, Poul-Henning Kamp wrote:
>> But you can only convert that UTC timestamp to a realtime_t (and >> vice-versa) for timestamps where the conversion is defined. > >Then I suppose it wouldn't make sense to use your realtime_t format >to store the events in calendaring / scheduling programs, You are right. Such "out of domain" usage of time_t is a major part of the trouble with the current handling of leap-seconds. >You'd then need to be able to store events in the program several >different ways, fixed either to local time, UTC, or "real" TAI >depending on which happens to be relevant to the particular event. Indeed, but that is a different task from what I am trying to specify here. I'm only trying to do the API for dealing with present and past time and timeintervals past us, in a computationally efficient manner. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
