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 <[email protected]> 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 > > _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
