An all to real point that I had overlooked inadvertently. I think adding a timezone parameter would be a fine change to the API. I'll look at it this evening, I've been meaning t Chris Heller SAS - Advanced Analytics Teragram Research & Development phone: 1-617-576-6800 x54237 mobile: 1-617-460-3643 email: heller@teragram.com On Nov 6, 2011, at 5:28 PM, Brandon Allbery wrote:

On Sun, Nov 6, 2011 at 17:25, Heller Time wrote: I rationalized the use of unsafePerformIO in the library by deciding that it was only being used in the case of a LocalTime instance (a user could always stick to UTCTime and avoid the issues) and that unless the machine running the program using time-recurrence was traveling across timezones (and the system was updating that fact) the program would essentially be referentially transparent :)

There's also late-night hackers doing stuff when DST changes (as it did in the US last night and Europe a week ago).

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Last night I modified the CalendarTimeConvertible type class. I added a function toCalendarTimeWithTimeZone, which adds a time-zone parameter, and eliminates the need for the unsafePerformIO in the LocalTime derivation. However this morning I realized that this was not the right approach. The problem is that LocalTime is under-defined, and the correct solution is to in fact not derive CalendarTimeConvertible for the LocalTime type. Instead one should think of a CalendarTime as meaningless without a time-zone, and therefore you cannot derive from CalendarTimeConvertible without one. This means users should stick to either the UTCTime derivation of CalendarTimeConvertible, or the ZonedTime derivation (which is in fact a LocalTime plus a TimeZone as desired). -Chris On Mon, Nov 7, 2011 at 2:56 AM, Chris Smith wrote:

On Sun, 2011-11-06 at 17:25 -0500, Heller Time wrote:

...

 unless the machine running the program using time-recurrence was traveling across timezones (and the system was updating that fact)

Note that this is *not* an unusual situation at all these days.  DST was already mentioned, but also note that more and more software is running on mobile devices that do frequently update their time zone information. Unpredictably breaking code when this occurs is going to get a lot worse when people starting building Haskell for their Android and iOS phones, as we're very very close to seeing happen.

-- Chris