Time library design proposal

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Wed Feb 2 06:36:49 EST 2005

"S. Alexander Jacobson" <alex at alexjacobson.com> writes:

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

And your proposal actually makes this worse. It encourages working on
a year-of-the-century and century separately, which was the cause of
the Y2K problem. It's better to encourage working on the year number
as a whole, so all rollovers happen automatically.

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

If you want to prevent constructing dates with such years, it can be
done when the Date object is constructed. I'm not convinced that it
would be a good idea though (perhaps the program uses 1.01.0001 as
a reference point to simplify calculations? or as minus infinity in
a time span, since our library doesn't support infinities?).

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

You can prevent it by checking the range in the constructor function.

You must do this anyway for the day of the month, so why not for the
minute of the hour?

BTW, I would prefer that out of range values cause adjustments
of higher units, as in most date calculation libraries in various
languages. This simplifies computing things like "the beginning
of the next month" which work in December too.

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

If we cared that much about memory, we would pack the whole date +
time in a few bytes or something.

I would just use the 0:00:00 time.

   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

More information about the Libraries mailing list