> SM> TimeDiff has a perfectly well-defined meaning for Eq
> and Ord: one
> SM> TimeDiff is equal to another iff all the fields are
> respectively equal.
>
> Yes, sure, Eq and Ord are defined by
> deriving (Eq, Ord, ...)
> but this does not make much sense if the representation for a
> particular duration is not unique. All I'm asking for is a unique
> representation for a duration and I do not see how you can do this
> using not uniquely defined terms like "month" and "year".
TimeDiff isn't a "duration", it's a way of specifying time offsets whose
duration depends on the base to which the offset is being added. If we
only had constant-duration offsets, then there would be no way to say
"give me a ClockTime for this time next Wednesday".
The problem is really that all the different kinds of offset are lumped
into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths, and
so on. TimeDiffSeconds is a constant-duration offset, but
TimeDiffMonths isn't. The problem with lumping them into one type is
that if multiple components are non-zero, you don't know in which order
to add them.
The TimeExts library gives you separate differences like these, BTW.
[snip]
> SM> This isn't a problem with the spec, I think. A
> TimeDiff of "1 month" is
> SM> precisely a difference, which, when added to a given
> ClockTime, produces
> SM> a ClockTime which is one month later (with respect to
> some timezone,
> SM> presumably UTC since it isn't specified otherwise).
> That is, January
> SM> 12th 12:00 UTC becomes February 12th 12:00 UTC, and
> so on. Adding one
> SM> month to certain ClockTimes is meaningless: eg.
> adding one month to
> SM> January 31st doesn't work.
>
> Unfortunately, with UTC, this goes on to make adding *anything* except
> seconds to certain ClockTimes (namely the instants of leap seconds,
> eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly
> legal UTC time on a day with a leap second) meaningless.
That's right, and here I'm not sure whether the right behaviour is to
raise an exception or to "roll over" to the next nearest date/time. I
believe TimeExts does some kind of rolling over, but I'm not sure of the
exact semantics (George?).
> My take would
> be to look at an established standard for expressing time durations
> (eg, ISO8601) and just adhere to that (but not the POSIX standard,
> please!). Personally, I think that it is unacceptable to make
> something like addToClockTime a partial function.
Ok, ISO8601 seems to specify only constant-duration time intervals, but
allows them to be given in terms of years, months, days etc., where a
month is specified to be 30 days, it seems, and similar approximations
are made for the other units. This seems very odd to me, but if that's
what you want... (it's possible I'm misreading the standard, or maybe I
got hold of an old version though).
> SM> At least, that's how I believe it is supposed to work. GHC's
> SM> implementation *is* completely wrong (which is
> perhaps where some of the
> SM> confusion comes from), but the TimeExts library can
> be used instead of
> SM> TimeDiffs.
>
> Well, so you agree that the behavior of the Time module is
> unspecified! Of course, I'm not blaming GHC's implementation which
> cannot be right under these circumstances.
Yes, it's unspecified, but I also think many people misinterpret it to
be more broken than it actually is.
> SM> This is a perfectly reasonable definition of absolute
> time, we don't
> SM> need to talk about TAI at all, except to define what
> the epoch means.
>
> Agreed! So what is epoch? Is it
> "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"?
I guess so... GHC's implementation will be whatever the C library uses,
which I assume is the one you specified above (at least on a decent
implementation).
Cheers,
Simon
