Poul-Henning Kamp wrote: > First of all, I'm not particular wild about floating point numbers,
Then others will feel the same way and will always immediately cast the returned values into integers, either rounding to seconds, scaling to milli- or microseconds, or splitting into two ints holding the seconds and the fractional part. I'm not arguing against your position (perhaps for it), but the API should be designed to gracefully handle awkward usage. In particular, should truncating into 32-bit signed ints leave you in a "reasonable" range of dates? And if you are actually considering placing the epoch in the future, what are the implications for casting the values into unsigned ints? > With binary128 we get 112 bits, which is enought to time individual QED > events in the Carboniferous Era. This was the point about the Planck time. The universe is big and time is long. No single API can address all use cases. Choosing the applicable range and establishing edge case boundaries is an important part of the exercise. It will strengthen, not weaken, the design to describe its constraints accurately. Rob _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
