[Boost-users] [Date-Time] Issues

From: Andrew V. Bronnikov (a_bronx_at_[hidden])
Date: 2004-01-29 04:10:10

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
are very important in our project related with time series, so I
immediately started to read docs, and tried to incorporate the lib as
it became possible for us. As usual, problems hadn't kept waiting...
:)

Issues:

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.

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.

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?

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

  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<posix_time::hours>(), _1)]

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?

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.

Thanx for the great work anyway!

With best regards,
  Andrew V. Bronnikov.