In message <5db9794a-4952-4a3b-98af-65e9573b2...@develooper.com>, =?utf-8?Q?Ask _Bj=C3=B8rn_Hansen?= writes:
>This is not a general date and time handling API; just a timekeeping one. Correct, people seem to be confused about this, so let me explain: We need an API which tells you what time *it is*, for instance for recording and ordering transactions in a database or to *measure* time intervals. We also need to be able to coordinate activities between loosely coupled computers, for instance robots in a factory, and that mandates that we have to be able to look into the future too. This API needs to be fast, and it needs to work without consulting databases, files or servers. That's what my API proposal is about. By basing the timescale on accumulated SI seconds, you can predict the occurence of events in the future, as long as you express the time until they happen, in units of seconds. But you can not express the time until future events happen in minutes, hours, days, weeks, months or years, because all of those have varaiable lengths, measured in seconds. For that another API is needed, one that understands timezones, DST and leap days and leap-seconds. That "calendrial" API I will leave to others to work out. I've probably added to the confusion by specifying the linkage between the two APIs, but since this discussion is fundamentally about how computers deal with leap-seconds, that was a very important aspect of the API to cover. Apart from this confusion, I have yet to see any serious objections to my proposal ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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 LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs