Time library design proposal

S. Alexander Jacobson alex at alexjacobson.com
Tue Feb 1 23:42:11 EST 2005


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!

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

Perhaps mkYear returns an error if the argument is 
not a four digit year.  The point is to make it 
difficult to make appointments for times that 
occured during the Roman Empire.

>> 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.

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.

>> 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.

Note: I would grant that Time without Date is a 
lot less useful but it seems like the way to go 
once you have a Date type.  Perl's incomplete type 
misses the point I am making here.


-Alex-



______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com


More information about the Libraries mailing list