Time library design proposal

[Benjamin Franksen]

On Wednesday 02 February 2005 05:42, S. Alexander Jacobson wrote:
> The overall goal here is to make sure that when
> you have a function that takes a Date or Time
> type, the values are consistent with the intended
> invariants of the type!

Right. But see below.

> On Wed, 2 Feb 2005, Marcin 'Qrczak' Kowalczyk wrote:
> >> or 4 digits.  Why not define year like this:
> >>
> >>    newtype Year = Year Int -- don't export constructor
> >>    mkYear century centyear = Year (100*century+centyear)
> >>    mkBigYear millenium cent centyear = ...
> >
> > Because it's easier to use the actual year number.
>
> Ok, but we have the common enough case of 2 digit
> vs 4 digit year that we might as well handle it.
> The Y2K problem is an existence proof

I support most of your suggestions, but this one makes no sense at all. Just 
use

	twoDigitYear year = year `mod` 100

if you really want only the last two digits.

> >> 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:
> >>
> >>    data Hour =  H0 | H1 | H2 ... H23
> >>    data Minute = M0 | M1 | M2 ... M59
> >>    data Second = S0 | S1 | S2 ... S59
> >
> > Again, it's simpler to use actual numbers. These values almost never
> > appear as literals in a program, so they would have to be converted
> > to/from numbers anyway, which is unnecessary and no other language
> > does this.
>
> Its only simpler to use actual numbers if the
> library does not provide the services to make it
> easy to use these values.

Let us not talk so much about data representations. Most important is the 
interface. We can have Data as an ADT and use constructors that check 
validity of month & day values and throw exceptions if check fails. Same with 
hours, minutes, etc..

> And we should certainly prefer to produce errors
> at constructor time rather than at destructor
> time.  It should not be possible to construct
> a Time like 43:84:00.

Yes.

> >> 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?
>
> Are you seriously saying that you never have use
> for a Date without a Time?  On what date were you
> born?  In my particular case, I am storing a lot
> of dates and don't also want to consumer memory
> for Time data that I won't use.

I don't buy the memory wasting argument, but still aggree, that a 
(Calendar.Gregorian.) Date should only contain year, month, day. The other 
thing should be TimeOfDay. And then we would have Time = (Date, TimeOfDay) 
(or a data type instead of tuple). My argument: A thing should be what its 
name says it is. When I talk about date I mean date and not date plus time of 
day.

Ben
-- 
"The CIA is Wallstreet. Wallstreet is the CIA." (Mike Ruppert)