Concerning Time.TimeDiff

[Simon Marlow]

=20
> On Monday 23 June 2003 05:35, Simon Marlow wrote:
> > you can't accurately use
> > addSeconds or addPicoseconds on a CalendarTime in the future without
> > knowing where leap seconds occur.  This is an interesting=20
> bug/feature
> > that I just realised.
> Similarly, converting between ClockTime and CalendarTime in=20
> time zones with=20
> daylight savings is somewhat unpredictable.  In my time zone, the=20
> determination of when to set clocks ahead has changed a=20
> couple of times in=20
> the past 20 years.

This is true; currently we rely on the C library for a correct
implementation of this, and I think we have to continue to do that
because it involves consulting the timezone data that usually comes with
the OS (we don't want to have to install a load of timezone stuff with
GHC, for example).

One thing that you can't do with the current proposed interface is ask
questions like "are they using daylight savings time in New York right
now?".  Indeed, the only way I know to do this on Unix is non-standard:

> TZ=3D/usr/share/zoneinfo/America/New_York date
Mon Jun 23 12:34:26 EDT 2003

Cheers,
	Simon