From: Peter Simons [mailto:simons@cryp.to]
A bank, for example, can't store its financing data in TAI, because TAI knows only the difference between two points in time. Between now and some day in the future, exactly 'n' seconds will pass. If that day is in the sufficiently distant future though, your mortgage repayment won't be due on April 1st some year, but on March 31st a second before midnight. Therefore these applications really need to store _calendar time_, which would be UTC et all.
Ahh, excellent example. So are there disadvantages to using, say, UTC, as the underlying representation? We can map UTC to TAI accurately for past and current dates (and those in the near future), and for the more distant future we accept that any conversion to TAI is only an approximation. Is there a need to support two different implementations? The types of systems I deal with would all use UTC/calendar-time, and I don't think I'd ever have a use for TAI (but I'm sure there are people that do).
From: Graham Klyne [mailto:gk@ninebynine.org]
Turning to the more general discussion of time... how complex a time library do we want? What sorts of things do folks actually want to do with time values most of the time?
One specific: I've used a language to implement a time-keeping system where addition of time durations was performed modulo 24hours e.g. if you added 2 hours to 23 hours, you got 1 hour. That made it impossible to sum the hours in a 40-hour week using that datatype... So being able to specify a variety of input and output formats for durations is desirable. I may want to specify 2 weeks, or 14 days, or 336 hours. I view timezone support as a layer over a correctly functioning UTC implementation. You want to represent all your times in UTC (well, something canonical) and have functions to input/output those in a variety of formats and timezones. Also, a String -> IO Time function that used the current locale to determine the timezone would be ideal for localising apps where the user entered times. I've seen criticism of the Java time support, mainly because it required you to specify a Calendar i.e. you had to perform all time operations in the context of a Calendar. While correct, it was considered too complex for simple things like "get me the time now". So maybe a simple default library, using the Gregorian calendar, that's capable of answering questions like: - how do I get the current time? - how do I find the start of the next quarter? - what day of the week is it today? - how many Mondays are in this month? - etc Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************
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
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.
participants (3)
-
Bayley, Alistair -
Keean Schupke -
Peter Simons