On 23 January 2012 08:05, Poul-Henning Kamp <[email protected]> wrote: > You can always compare them ("is date1 before, the same or after date2") > but you cannot subtract them and get a precise time-difference, if they > span a potential leap-second application. > > One obvious hack is to add a "double *error" argument which is > set to the potential number of leapseconds between the two dates. > > But a similar problem appears as soon as we try to compare or subtract > two timestamps in two different civil timescales, which includes > UTC in my design: Som looney politician might change the timezone > before we get there.
FWIW, JSR-310 handles that case, but its complex. We (currently) allow the possibility to hold multiple versions of the time-zone rule data. A ZonedDateTime (date and time with time-zone and offset) will generally use the latest version of the tz rules data. But if that make the datet-time invalid (because someone has updated the tz rule data, user or politician), then the code will search the history of tz rule data until it finds a rule set that does make the date-time valid. The leap-second case is also handles, by recording UTC as days and nano-of-day (a flexible break in the notation that handles the change), or by ignoring leaps via smoothing (UTC-SLS by default). > It's the calculation of durations between timestamps on UTC in the future > which is impossible, simply because they are undefined. Not necessarily. The duration in days is well-defined, and thus a UTC instant stored as days+nanos is well-defined for the future. The problem here is that the meaning to a human of a point defined in the future solely in TAI seconds will change over time. Thus TAI is of most use solely as a clock defining now. The problem is that it is easy for a user to get now, add 1000 * 86400 seconds to it and then see the resulting time change over time. Thats why I (and others) see TAI as unstable as a format for human timekeeping (useful for exact duration based tasks, but those are relatively rare in my experience). Reading the other mails, I think you can see where the primary concerns are: - floating point - I and others are sceptical of that - sole focus on TAI - for time geeks its correct and "real", but not necessarily everyone thinks its "right" - epoch choice - TAI, 1970 or some random choice I think the first point looks wrong, but I'm not a kernel guy, so thats who should guide you. A struct would be more Java-ish, but thats probably as far as I can go. I think you can mitigate the second objection by providing conversion to UTC and a leapless 86400 non SI second scale in the core, and separate from the breakdown to YMDHMS. ie YMDHMS is not the only "broken down" form that users care about. The third point is a detail. Stephen _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
