> 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.
> There's a lot of business programming for which days are far more important > than seconds, but in those cases (interest, book releases, etc), it's very > much local legal time that matters, not a continuous timescale. Correct > and current daylight saving time transitions are more important than leap > seconds and milliseconds in those cases. I think the key idea is that there are several units of time and things like leap seconds, time zones, and leap years make conversion between them far from simple. We want to work with time in units of: SI seconds Days Years kilo- and mega- years Picking an API that focuses on one makes it hard to do things in the others. There are also months, but they are sufficiently non-uniform that nobody expects simple arithmetic conversions to work. If we are going to make any progress in this area, I think we have to come up a collection of APIs that cover all the needs and a good description of how to decide which one to use, and why. ------------- It might be possible to use seconds to describe times in the future if you also carried along some sort of fuzziness range. The idea is to be able to say: X seconds from now, but I only need it to the day so I don't care about leap seconds or DST. (But that breaks when your country jumps across the international date line.) It might help if routines like localtime and gmtime had another parameter to tell them the round-off granularity: minute, hour, day, month, year, century... -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
