[project @ 2000-06-19 13:28:35 by simonmar]

[project @ 2000-06-19 13:28:35 by simonmar]
Time fixes from Michael Weber <michael.weber@post.rwth-aachen.de>:

  * `toClockTime' previously didn't honor the `tz' field of a
    `CalendarTime', which led to time warping when applying

      => (toUTCTime (toClockTime ... (toUTCTime (toClockTime someTime) ... )))

    continuously.

    Now it accepts at least <local>- and UTC-encoded `CalendarTime's
    (TODO: test, whether all timezones work) and converts them
    correctly to <secs from epoch>-format (which is always UTC, as one
    might have guessed).

  * `addToClockTime' now works.

    Previously, `tz' seconds were added(!) when used like:

      => addToClockTime noTimeDiff someTime

    which is clearly wrong.
    Now, the following (hopefully) always holds

      => someTime == (addToClockTime noTimeDiff someTime)

  * `diffClockTimes' works correctly, and is the dual to
    `addToClockTime', i.e.

      => diff == ((addToClockTime diff someTime) `diffClockTimes` someTime)

    should now hold for all diff, someTime

    Previously, it reports ugly diffs at {min,hour,day,...}-breaks,
    for example:

      => "2000/06/18 01:00 UTC"
            `diffClockTimes` "2000/06/17 23:00 UTC" == 1 day, -22 hours

    whereas now it emits "7200 secs". This number can be converted
    with `normalizeTimeDiff' to "2 hours".

  * added `normalizeTimeDiff', which calculates year, month, days,
    etc. out of an unnormalized `TimeDiff' (generated by
    `diffClockTimes', for example)

  * `formatTimeDiff': added the missing "%c" case. The
    format is proprietary, though... Is there a nicer one?