time since the epoch

[Peter Thiemann]

    SM> TimeDiff isn't a "duration", it's a way of specifying time offsets =
whose
    SM> duration depends on the base to which the offset is being added.  I=
f we
    SM> only had constant-duration offsets, then there would be no way to s=
ay
    SM> "give me a ClockTime for this time next Wednesday".

[nitpicking] Oops, this is not the purpose stated in the library report:
"The TimeDiff type records the difference between two clock times in a
user-readable way."=20

Anyway, the sort of specification that you are talking about is really
a pain IMHO. Actually, you could not use TimeDiff to state it,
either. [ISO8601 allows it but I think it's too imprecise to be useful]

    SM> The problem is really that all the different kinds of offset are lu=
mped
    SM> into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths,=
 and
    SM> so on.  TimeDiffSeconds is a constant-duration offset, but
    SM> TimeDiffMonths isn't.  The problem with lumping them into one type =
is
    SM> that if multiple components are non-zero, you don't know in which o=
rder
    SM> to add them.

It is always a problem to lump things with different semantics into
the same type :-) What I'm arguing is that there should be only one
fixed-duration offset datatype and it should be in terms of (seconds,
picoseconds).
Other fixed durations can be easily defined in terms of this
datatype.=20
I'm still not sure that you actually want base-dependent offsets, but
again they can be easily defined on top of the fixed duration
datatype. And they should be specified separately from the base
functionality.

Certainly, differences between clock times should be in terms of the=20
fixed-duration datatype.=20

    SM> The TimeExts library gives you separate differences like
    SM> these, BTW.

That sounds good, I'll look at it again (it's pretty much bare code,
so I might have overlooked something).

    >> Unfortunately, with UTC, this goes on to make adding *anything* exce=
pt
    >> 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 perfect=
ly
    >> legal UTC time on a day with a leap second) meaningless.

    SM> That's right, and here I'm not sure whether the right behaviour is =
to
    SM> raise an exception or to "roll over" to the next nearest date/time.=
  I
    SM> believe TimeExts does some kind of rolling over, but I'm not sure o=
f the
    SM> exact semantics (George?).

As far as I read ISO8601 (which also has a notation for durations)
this is unspecifed :-) And as far as I read TimeExts.lhs it does some
sort of rollover. My take would be to specify the behavior for adding
something like a TimeDiff to a base date in a consistent manner and
then cast that in stone. If there is a (reasonable) standard for this
kind of calculation, then this should be the basis for the specification.

    SM> Ok, ISO8601 seems to specify only constant-duration time intervals,=
 but
    SM> allows them to be given in terms of years, months, days etc., where=
 a
    SM> month is specified to be 30 days, it seems, and similar
    SM> approximations

If I remember correctly, then ISO8601 specifies durations up to a day,
but bails out at months and years.=20

    >>=20
    >> Agreed! So what is epoch? Is it
    >> "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"?

    SM> I guess so... GHC's implementation will be whatever the C library u=
ses,
    SM> which I assume is the one you specified above (at least on a decent
    SM> implementation).

Unfortunately, if you are using time(2), then you'll get rubbish (from
the manual page):

DESCRIPTION
       time  returns the time since the Epoch (00:00:00 UTC, Jan=AD
       uary 1, 1970), measured in seconds.
[...]
NOTES
       POSIX.1  defines  seconds since the Epoch as a value to be
       interpreted as the number of seconds between  a  specified
       time  and the Epoch, according to a formula for conversion
       from UTC equivalent to conversion on the na=EFve basis  that
       leap  seconds are ignored and all years divisible by 4 are
       leap years.  This value is not the same as the actual num=AD
       ber  of seconds between the time and the Epoch, because of
       leap seconds and because clocks are  not  required  to  be
       synchronised  to  a  standard reference.  The intention is
       that the interpretation of seconds since the Epoch  values
       be  consistent;  see  POSIX.1  Annex  B  2.2.2 for further
       rationale.

The problem is that this notion of time is discontinuous and sometimes
not strictly increasing. See the various references pointed out by
members of the list for why this can be a problem.

-Peter

PS, I see you are trying to follow-up to haskell-cafe, but I'm not
subscribed to that list.