"Simon Marlow" <[EMAIL PROTECTED]> writes: >> (My preju^H^Hference would be to store a date-time internally in a >> posix-like manner (seconds,microsecond since the epoch).)
> I'm still not sure I understand why the Time library is considered to be > broken I was probably a bit quick on the trigger there. Sorry! It't been a while since I tried using CalendarTime and friends; I did have some difficulty making things fit, and eventually gave up the whole thing. My impression (which may well be a wrong one) was that others also had trouble adapting the library to their uses, too, and that the Time library was one of the less successful ones. Looking at it now, possible criticisms could arise from the data types containing redundancy and non-uniqueness: e.g. one can easily construct non-consistent CalendarTimes, and there are multiple ways to represent the same interval as TimeDiff -- in fact, two TimeDiffs may or may not be equal, depending on what CalendarTime they apply to. (The 'deriving' of Eq makes this a moot point, perhaps, but seems to make equality rather non-intuitive) It seems that TimeDiffs perform two functions; deltas for ClockTimes (in the functions) and intervals of calendar times (specification of the data type), and I'm not sure it's a good idea to mix those. Let's sketch a different suggestion. I haven't given this a lot of thought, so feel free to shoot it down! <sketch> ClockTime -- as is ClockInterval -- a delta for ClockTimes, diffClockTimes:: CT -> CT -> CI CalendarTime -- as is, only used as *output* from functions -- for input, have non-redundant data structures CalendarDate -- normal, non-redundant date information CalendarYearDay -- (year, day of year,time) -- add functions for computing the correct CalendarTime from any of these CalendarInterval -- a (user constructed) time interval, which allows the user to do normal arithmetic (e.g. "add 1 month") to CalendarTimes Notably, ClockIntervals and CalendarIntervals aren't mixable; using CalendarIntervals (probably?) require locale information, and converting one into the other (probably) requires a specific reference point in time. </sketch> Since it's almost Christmas, I'd also like a way to specify things like "first Tuesday of every month", or "the day before (last Thursday of every month)". And a GHC target for my Palm Pilot :-) We could build a really cool Cron replacement, and become rich and famous. (BTW, > the weekday/yearday in a CalendarTime are ignored by the > toClockTime in GHC's Time library, so you can set them to anything). This seems to be standardized behaviour specified in the Report) Anyway: Oh well. I'm not using Time at the moment, so its not an issue that will ruin my holiday for me :-) When I have a concrete use for it that it doesn't support, I'll be sure to let you know! :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe