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