In message <caczrw9ccp982n_tbty_st3xbsd_+hazw0+ofttrcwb_6mhb...@mail.gmail.com> , Stephen Colebourne writes:
>> >There is an IEEE spec for a large decimal number, which would be >> >preferable. Or a 96/128 bit integer. >> >> Only, it is not implemented anywhere, binary128 is. > >Fine, but I'm very unenthused about floating point numbers in general. >I'm not sure you've made your case for not using a 128 bit integer, >defined as (say) attoseconds. First of all, I'm not particular wild about floating point numbers, but the fact of the matter is that: A: Time is measured in seconds, with a fractional part. B: We want a datatype which supports normal sums and differences. Both of which point to a floating point format, where operations will naturally do what people expect from them. Representing time in a integer count of a decimal fraction of seconds is a really bad idea on a binary computer, that just leads to bugs. It also means that numeric contants for common time intervals like "1 second" become unweildy constants in the program. See timeval/timespec use for plenty of such messes. If you want a 128bit counter format, the units should be "1/2^N" for some suitable N, most likely 64. This would be workable, but still suffers from unweildy constants, in particular for time intervals less than a second. I've come to the conclusion that we have two choices: Either a totally opaque time-type, which can only be operated on with function calls that understand it, or we can lay it out in a floating point type that intuitively does what people expect with common algebraic operations. The latter is clearly preferable, if the objective is to reduce the number of mistakes programmers make. >Exactly why I was asking about the purpose of this API. I'm not seeing >it as a time API. My intention was that this would be API that interfaces programs to the operating systems (ie: kernels) timekeeping facility. >My concern with what you have proposed is >that the second part (the time-zone part) does imply a time API, but >without sufficient control. What controls are missing ? >The JSR-310 spec effectively only requires a clock source from the OS. And my API specifies the API to that clock source. >Currently, my view is that the low-level API that you are defining >should offer all three of the above, as they are the building blocks >for everything else. Exactly. >Finally, I do think that if its called TAI, then it should use the TAI >epoch. No, to aid finding programmer bugs, it should use an epoch that will generate large errors if^H^Hwhen programmers make mistakes. -- 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
