Ben Rudiak-Gould wrote:
Seth Kurtzberg wrote:
Timekeeping is crucial for certain applications, which happen to be the ones I work on. [...] If you ignore the realities of time (that is, that the universe isn't much interested in our simplifications) you get your satellite in the wrong place, and you lose $100 million. [...] If it's worth doing, don't return the wrong answer. [...] The universe doesn't stop for that period when POSIX pretends that it does. [...] Given the choice of reality or POSIX, it seems to me that reality is a more sensible choice.
I honestly think you ought to sit down calmly, take a stress pill, and think things over.
You want the library to do the Right Thing. Great, we all do. But it's IMPOSSIBLE. If it were difficult, we would have just done it, and none of this long discussion would have happened.
What, precisely, do you want from a standard time library that Ashley Yakeley's proposal could provide and doesn't?
I want to compute the correct interval between two timestamps. I guess I not only don't see why it's impossible, I don't even see why it is difficult. The difficulty, if it exists, comes from converting the absolute time into calendar time, but even that isn't really difficult. The firmware in a GPS receiver does it. So it is clearly not impossible.
Do you want it to interface with a GPS receiver, or connect to an Internet time server to get the current time? It doesn't make sense to include such things in an initial proposal. Once we have some basic datatypes for UTC and TAI times, then we can easily write other libraries with the appropriate functions of type IO AbsoluteTime.
That's mixing apples and oranges. I don't buy the argument that it is better to not handle both time representations until you have an IO class to fetch the representation. Why is it unreasonable to ask the library to tell me the correct answer from, say, the current time to some time in the future? Simon said there will be conversion functions between POSIX time and TAI time. But the thread seems to be saying the reverse. The thread also seems to be saying that, because we can't guarantee that a leap second table will be updated correctly, we should tolerate errors in time of up to 12 seconds (the current aggregated leap seconds). I just don't see why that's necessary.
-- Ben
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
!DSPAM:420c7e71263435943228596!