k.schupke at imperial.ac.uk
Wed Jan 26 15:06:00 EST 2005
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
>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
Ironically thats starting to get towards the kind of specification I was
Perhaps this would be more acceptable as a project with the following
We split this into two libraries, one would implement a time difference
Time would be in relative, measured milli (or micro) seconds. Time would
from a standard epoch... instances of Ord, Eq etc would be provided...
The second would be a type class for implementing calendars. The
allow conversion to and from 'absolute' time, including timezones...
People could then implement different calendars that fit with the
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.
More information about the Libraries