I think it is widely agreed that the time and date structures in the standard libraries are brok^H^H^H^Hslightly less than useful.
I suggest you feel free to rewrite it as you see fit, and then lobby for its inclusion in the hierarchical libraries.
(My preju^H^Hference would be to store a date-time internally in a posix-like manner (seconds,microsecond since the epoch).)
But a ClockTime *is* implemented as (seconds,picoseconds) since the epoch. CalendarTime is just a human-readable interpretation of the ClockTime, or a way to synthesise a ClockTime from a known date/time. (BTW Peter: the weekday/yearday in a CalendarTime are ignored by the toClockTime in GHC's Time library, so you can set them to anything). I'm still not sure I understand why the Time library is considered to be broken; sure I can see that our implementation of addToClockTime is wrong (adding one minute shouldn't always be the same as adding 60 seconds, for example), but is the design fundamentally wrong? GHC's TimeExts library (package lang) is allegedly a better implementation of addToClockTime/diffClockTime, if anyone is looking for one. Cheers, Simon
"Simon Marlow"
(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
On 20 Dec 2002, Ketil Z. Malde wrote: (snip)
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. (snip)
That is the slippery end of the wedge - next we'll be wanting standard library functions for calculating when Easter and Id-ul-Fitr are. (-: The calendar source code I'd referred to before was indeed written to get all this type of stuff into my m100 - I type "calendar 2004" or whatever and hand that to install-datebook. (Is all the world on a seven-day week? I wonder how that came about.) -- Mark
Ketil Malde writes:
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.
Take a look at "remind" for a language that can express all these things, *and* knows the date of Easter.
http://www.linuxjournal.com/article.php?sid=3529
http://www.roaringpenguin.com/remind/
Not suggesting we copy this directly, of course!!
--KW 8-)
PS: Happy New Year, everyone!
--
Keith Wansbrough
participants (5)
-
Jerzy Karczmarczuk -
Keith Wansbrough -
ketil＠ii.uib.no -
Mark Carroll -
Simon Marlow