On Thu, 29 Jan 2004 15:10:10 +0600, Andrew V. Bronnikov wrote

Hello, All!

When I was familiarized with the great Boost Library one of the most inspiring part of it was the Date-Time Library. Date and time issues...

Thanks!

1. why gregorian::date and posix_time::ptime have no default constructors (possibly initializing them into some special value - good candidates are not_a_date_time, neg_inf or local_time (see next issue))? Lack of default ctors doesn't allow direct use of date-time objects in tuples and other containers requiring default- constructible classes.

Because I generally dislike default constructors and I was extremely concerned that I would pick the wrong default. However, this has started to come up more frequently and the consensus seems to be not_a_date_time, so I guess I can add them. Of course you can trivially derive from gregorian::date and posix_time to provide these yourself. Or you can trivially modify the code to support this.

2. why special_values enum has no "local_time" (or "now") item? It seems "special" enough, and - more important - it allows to pass the "initialize as current time" directive as a time initialization policy in templates.

True, it is special. However, by which clock would you suggest we judge 'now'? The local computer? Perhaps a network clock source? In the date-time library there is a strict separation of representations of time and things that meaure time (clocks). The idea is that clocks are adapted to the time representation instead of the other way around. This is the inverse of time_t where the time representation is completely tied to the clock -- in my opinion a fatal flaw in the design that leads to problems like not being able to represent times before 1970-Jan-1.

3. why date, ptime, durations have no setters for their components (days, hours, minutes etc)? I guess it related with validity checking issues - am I right, or there are some other reasons?

Yes validation and maintaining the general concept of an 'immutable object'. Overall providing these as immutable objects simplifies the code, reduces the interface, and makes code easier to understand. Some references on this: *http://en.wikipedia.org/wiki/Immutable_object *http://c2.com/cgi/wiki?ImmutableObject *http://www.javapractices.com/Topic29.cjp

4. why hours(), minutes() etc are classes, not simple time_duration factory functions? What the another level of inheritance for? Consider using a time_duration in lambda expressions (e.g. in the Spirit semantic actions):

Ok, I can assure you this is a new use case :-) Anyway, no real reason. These could be changed into factory functions, it's just that some older compilers have problems with template functions...

posix_time::time_duration dt; .... rule<> hours = uint_p [var(dt) += posix_time::hours(_1)]

This will not compile because hours() is not a function. Instead, I must use something like a lazy constructor:

rule<> hours = uint_p [var(dt) += bind(constructor(), _1)]

But all and all not really too bad :-)

but it looks not so short as before. And - surprise! - it doesn't compile too, just because of the next problem:

5. neither of date, ptime or time_duration defines operator+=(). What is the reason for denying it? It seems quite natural to have a set of assignment operators for date_time classes, isn't it?

These are in the current CVS version of the library and will be in the 1.31 release. I believe the release will be any day now...

6. it would be great if GDTL classes will support explicit/implicit conversion functions/operators from/to older standard types like a time_t etc. It will allow smoother transition from old libraries to the GDTL.

Again in the CVS version there is a from_time_t function. ptime t = from_time_t(0); //1970-Jan-1 0:0:0 However, I note that there is not a to_time_t function. Let me know if you really need that as it can be added.

Thanx for the great work anyway!

You're welcome! Jeff