Bayley, Alistair writes:
So are there disadvantages to using, say, UTC, as the underlying representation?
I really am not an expert, so take this with a grain of salt. My understanding is that you can chose your poison: * If you need accurate arithmetic with time, you essentially have to use TAI because everything else is quite simply not continuous, so any kind of math with that is very difficult to get right. (How many seconds does an hour have in UTC? Well, depends on the hour.) * If you need to handle points in time (calendar dates), you essentially have to use UTC because in TAI the information "24282794" may designate a different point in time today than it does in half a year. The representation you should use depends on what you are trying to do. So the good news is: Whatever you do, you lose. A really good library will almost certainly need both representations, plus the ability to convert between them, plus the ability to estimate the potential error, plus a way to update the table of leap seconds semi-automatically, etc. To be honest, I wouldn't want to be responsible for that task. ;-) Marcin 'Qrczak' Kowalczyk writes:
type TimeDiff = (Integer, Float)
With Float it gives 60ns of precision at the end of each second, and more precision near the beginning of each second.
You are right, of course. That's why I suggested the use of the type class Fractional a bit later in my posting. My suggestion is not to use Float -- or any other concrete type --, it is to store seconds plus a fraction of a second, because this representation is capable of representing arbitrary precision as long as your fractional type does. You can chose the accuracy you need by choosing your fractional type without changing the representation per se. If you decide to use "microseconds since the epoch" on the other hand, that is not possible -- neither is it with "seconds plus microseconds", like C's "struct timeval" uses. I'm always reluctant to chose arbitrary limitations for the user of the code; let the user make those choices, then it is his fault when things go wrong. ;-) Peter