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. *****************************************************************