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 <cdsmith@gmail.com> 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