you can't accurately use addSeconds or addPicoseconds on a CalendarTime in the future without knowing where leap seconds occur. This is an interesting bug/feature that I just realised. Similarly, converting between ClockTime and CalendarTime in time zones with daylight savings is somewhat unpredictable. In my time zone, the determination of when to set clocks ahead has changed a couple of times in
On Monday 23 June 2003 05:35, Simon Marlow wrote: 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=/usr/share/zoneinfo/America/New_York date Mon Jun 23 12:34:26 EDT 2003
Cheers, Simon