SM> I wrote a reply, but I don't really have anything new to say over what's
SM> been said already, so I'll keep it brief instead. The copy of ISO8601
SM> that I looked at is here:
SM> http://www.astroclark.freeserve.co.uk/iso8601/index.htm, but from what
SM> you said I'm guessing you're looking at a different version.
Oops, I guess I did. However, the 2000 version does not clarify
matters much more. It does, however, make the distinction between day
(= 24 hours) and calendar day (period until the same daytime is
reached again). Regarding, time periods it only specifies the syntax,
not the semantics. Oh well.
SM> Anyway, to sum up:
SM> - I agree that there should be a constant-duration time offset type.
SM> However, TimeDiff does actually fuction perfectly well as one at
SM> the moment, since diffClockTimes only fills in the seconds and
SM> picoseconds fields.
Ok. But there is the caveat that
TimeDiff { ... tdSec :: Int ... }
which will give rise to overflows in a few years.
SM> - I believe a reasonable interpretation of the other fields of
SM> TimeDiff is as base-dependent offsets. The current implementation
SM> in GHC doesn't do this, but you can use TimeExts which
SM> does.
In addition, it does not muddle months, years, etc together into one
TimeDiff value. This is a GOOD THING because you would have to specify
the sequence in which the various items are added to the reference to
get a well-defined behavior.
SM> - Our implementation of ClockTime uses C's gettimeofday(), which
SM> apparently is based a broken definition of the epoch. Oh well :-)
IMHO, the TimeDiff data type is the source of all evil (in Time, at
least). What about the following proposal for extending TimeExts:
* Add a datatype
data Duration = Duration Integer Integer
* Define the operations
addToClockTime :: Duration -> ClockTime -> ClockTime
diffClockTimes :: ClockTime -> ClockTime -> Duration
[[ and deprecate using them from Time ]]
* Write an explicit specification for the remaining operators.
This should not be much effort. [the overall goal being, of course, to
phase out the Time module]
For further cleanup, the stuff dealing with CalendarTime could be
moved into its own module Calendar. And it would be very useful to
have parsing functions like
parseTime :: String -> CalendarTime
[might have to be IO CalendarTime because the interpretation depends
on the local time zone, etc]
Cheers
-Peter
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
