Peter Simons wrote:
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. ;-)
Ironically thats starting to get towards the kind of specification I was looking for... Perhaps this would be more acceptable as a project with the following considerations: We split this into two libraries, one would implement a time difference or chronograph. Time would be in relative, measured milli (or micro) seconds. Time would be measured from a standard epoch... instances of Ord, Eq etc would be provided... The second would be a type class for implementing calendars. The functions should allow conversion to and from 'absolute' time, including timezones... People could then implement different calendars that fit with the framework, like the Gregorian, Chinese, Hebrew, or the Hijri Calendars. Chinese is particularly odd: - An ordinary year has 12 months, a leap year has 13 months. - An ordinary year has 353, 354, or 355 days, a leap year has 383, 384, or 385 days. Keean.