On 20 January 2012 11:29, Poul-Henning Kamp <[email protected]> wrote: > With the leap-seconds still unresolved, it is time that we get real about > time in the computer business.
True. I'm attempting to work out something better in Java at ThreeTen/JSR-310. Co-ordination may be needed here. > How anybody could get the demented idea that a mixed-radix format > for time representaiton could be a smart move is totally beyond me. Java only has a 64 bit primitive value, so we are effectively forced into using two numbers. > How many bits of resolution do we need ? The Java group decided on "nanoseconds in the age of the universe". Not that anyone needs to specify a point in the far future/past to the nanosecond, just that its easier to have a single level of accuracy for all time. The "age of the universe" was non-contentiuos. The nanoseconds part was a requirement driven by some database vendors that store amounts to nanoseconds (accurate or not). The Java spec currently uses 64 bit seconds and 32 bits for nanoseconds. Only one person so far has asked for attoseconds, and I think thats overkill myself. > We could invent a new data type, "int80_t" or something, but that > would be a lot of work, so let us just bite the bullet and use one > we already have: IEEE binary128 floatingpoint, also known as > quardruple-precision floating point. Floating point? What is 0.1 + 0.2? (Not coded in C for donkeys years myself) There is an IEEE spec for a large decimal number, which would be preferable. Or a 96/128 bit integer. > Next comes the question what we do about leap-seconds, and there > is only one answer that works in practice: We make them a > representation issue. > Our new timecale should run on the TAI timescale which does not > have leap-seconds or any other artifacts, and library functions can > convert that to UTC time, civil time etc, using a leap-second table > which can be updated as and when leap-seconds gets announced. When designing the Java API, I concluded that it was a user choice as to the time-scale they wanted. There are three choices: - TAI - UTC - "86400sec" (aligned to UTC days, but always with 86400 "seconds" - ie not necessarily SI seconds) Its a user choice because defining a time in the future will not be accurate if using TAI seconds alone. The code defines TAI and "86400sec" as epoch-nanoseconds, but UTC is defined as modified-julian-days+nano-of-day (up to 86401 seconds). My take is that the "86400sec" form is the one most users want, even though it is inaccurate (with rubber seconds via UTC-SLS). So, I don't think that running solely on TAI works in terms of what users want to do. So, it depend on whether you want your API to be user-facing, or as a basis for another level that adds the "86400sec" scale. > A IEEE binary128 number containing time on the TAI timescale > counted in SI seconds since 2012-01-20 00:00:00 UTC. The exact > epoch is not imporant, but it is a good idea to make it different > from all other currently used epochs, to make programmer mistakes > clearly visible. +1 on the epoch being different > ]] int tai_time(realtime_t *timestamp, double *error); > ]] int run_time(realtime_t *timestamp); Both look reasonable at first glance, but I'm not a user of the equivalent C APIs today, so my comments there are limited. > In all other cases, this timescale represents elapsed time in SI > seconds, and two successive calls to this function will always > return two timestamps in increasing order. A guarantee of always increasing would be useful. > We treat UTC as another case of the larger class of civil timezones. > Converts the timestamp to "broken down time" in the specificed > timezone, applying leap-second corrections, daylight savings time etc > as directed by the "tz" paramter. I'm sceptical of the time-zone approach. I find a user demand to record instants in time, but believe that they are days of 86400 "seconds". Does this API return a "broken down time" (fields) with a second-of-hour of 60? Again, while that is accurate according to UTC, I don't believe its what users *want* (it forces every query of seconds to have to handle leapsecs, which is undesirable for API usability). Its a tough problem. Form the looks of it, your API would provide good info, but you need to explain how a user would set timestamps in the future beyond the known leapsec horizon. I don't think this API can. Stephen _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
