Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-04-22 15:44:40


> I haven't had much of a chance to play with it yet, but my initial
> reaction is that I don't think it is ready for acceptance. At the
> very minimum, I'd expect to see some locale support rather than
> the hard coded names in English I found in greg_month.cpp!

I agree that that isn't well implemented and needs to be fixed to
work with locales.
 
> I also have reservations because it seems too large and complex
> given how little it seems to deliver.

In it's current form it delivers more than most date-time libraries
I a know about. Parsing, formatting, dst_rules, holiday calculation
algorithms, etc all take code and add complexity to the library.

> Finally, I'm not sure that I agree with the design premise, i.e.,
> that the calendars should be part of the date type. It seems to
> me that dates should be calendar-independent and the calendar
> should only come into play for I/O and operations on the date.

I'm not sure what you mean by I/O, but the 'calendar' is responsible
for defining the mapping between the label form (eg: 2002-1-1) and
a counted form. The counted form is used form is used for calculation
and comparisons. This mapping is fundamentally limited by the
'calendar system' and it's implementation. I'm wondering if the
word 'calendar' is confusing people. Maybe it should be called
'date system' instead. Does that make it clearer?

> If date is to be a template, I suggest that the template
> parameter(s) should only be used to specify precision and range.

I've actually been down this path and concluded that as far as
dates are concerned there is a dependency on the implementation
of the date system. For example, in the gregorian calendar there
have been anomolies in the handling of leap years in the distant
past. Extending the calendar range without actually researching
and implementing the required functions correctly would result
in errors. Time systems have similar issues.

Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk