Poul-Henning Kamp wrote: > To avoid thread-divergence, I have collected some responses here:
Am happy to see such an effort and agree generally with previous comments, expecially Mark's and Steve's. Will keep my editorial comments to a minimum (here) to squelch divergence, but I will point out that this of course doesn't address all civil timekeeping issues that have been discussed. Regarding editorial comments, would suggest these be excised from the document but that points of software engineering be described in more detail than usual; the stakeholders and potential readers won't all be programmers. For instance, examples of bad current usage should explain why they are bad. > Also, I disagree with choosing an epoch in the past to reduce exponent > changes: We should optimize to get maximum number of exponent changes > initially, to make sure code handling that gets debugged. We should probably > even put the epoch into the future, > to also get handling of signs tested. Lets make it 2026-01-20 instead. An interesting strategy. Some comments: 1) You'll get pushback against floating-point, especially quad FP. Benchmarks and data challenges are a good way to make the case. What is the cost to "get REAL" versus current libraries for different classes of systems and applications? 2) There is nothing magic about the 1000 year horizon. Certainly science cases extend very much further into the past and future. 3) How does this interoperate with Julian date, another floating-point format? Note that Modified Julian Date (MJD) was implemented precisely to avoid the extended precision needed to simultaneously support high precision and wide date ranges. Rob _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
