Re: Time library design proposal

Marcin 'Qrczak' Kowalczyk writes:

"S. Alexander Jacobson" writes:

...

newtype Year = Year Int -- don't export constructor mkYear century centyear = Year (100*century+centyear)

Surely .... = Year (100*(century-1)+centyear) ?

...

mkBigYear millenium cent centyear = ...

...

The type of hour minute and second should protect the user from 28 o'clock and making appointments for 31:101 PM So we probably want:

This depends on which calendar you are using. UTC sometimes has 61 seconds. The Ethiopian calendar has 13 months.

...

There are also lots of contexts where you want a time but not a date e.g. an alarm clock....

And there are contexts where you want a weekday and hour/minute but not a month or second (a weekly schedule), contexts where you want month/day but not a year (a holiday with a fixed date) etc. Where to stop?

This is hard to do if you insist of a calendar being represented as a single record representing points in time, with a one-to-one correspondence to a system clock. I rather think a calendar should let the user specify units in a more natural, flexible way. So I don't particularly like the "incomplete" proposal, filling out the record with Maybes. I'd rather have a (set of) calendar(s) that let me specify precisely which day, minute, or hour I mean, in a way that is natural to me. Perhaps something like: import Calendar.Gregorian easter :: Year -> Day easter yr = first (filter isSunday (daysFrom (springEquinox yr))) easter05 :: Year -> Day easter05 = easter 2005 easter_lunch :: Hour easter_lunch = hours easter05 !! 12 vacation :: [Day] vacation = daysFromTo (june 2005 !! 20) (august 2005 !! 25) -- I wish The coupling between a calendar (as in dates and hours) and time (as in a continous flow measured in seconds) should be loose, but one should of course be able to find out which day, hour, nanosecond any point in time is. -kzm -- If I haven't seen further, it is by standing in the footprints of giants