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
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