[boost] Re: Re: reminder about Date/Time formal review

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-04-23 21:59:38

"Jeff Garland" <jeff_at_[hidden]> wrote in message
news:LPBBLOEIMCKBCMMHJMGAKEBMDNAA.jeff_at_crystalclearsoftware.com...
> > 1. Generic base
> > I did not agree with design of generic base of the library. Separation
of
> > date and time does not look reasonable.
>
> Ok, but the basic premise is that a 'date only' library shouldn't depend
on
> 'time specific' things.  There are many programming problems that exist
> strictly at the 'date level'.

System I invision would not have this problems.

> >For one it's replication of code sometime. But mainly it's not flexible.
What
> >if I need 3 level date/time system that have day, hour and seconds? Or 2
level
> >time system that have only weeks and days. Generic solution may look
> >something like this (from top  of my head, only sketch ):
>
> This is done by replacing the time system and supporting types.

I wonder how you would you implement week/day day system, given the fact
that you have year/month/ydm hardcoded in generic part of the library. Or
time_duration assumes that time have hours, minutes and seconds but this
would not be the case in my first example. Do not mention output formats.

>
> > Generic class time_system_level
> > ...snip implementation suggestion...
>
> I think this would be an interesting approach to explore.  What you're
> suggesting (assuming I understand it and we could get it to compile)
> could unify the idea of the concept of time point.
>
> >     is_valid() // ?? why do we need that?
> >Could not we make sure that value
> > is valid always and throw an exceptions on invalid operations?
>
> Because some date-time systems will allow of 'not-a-date-time'
> values.  They need to be able to query for this state before
> they get the exception.
>
>
> >     operator-,+ will use some other class that encapsulate duration
instead
> > of two similar classes date_duration, time_duration
> >
> >     read-only property: unit_type    m_value;
> > }
> >
> > normalized_value<n,level_id> :=
> > uple( date_time_system_policies::level_unit_types::get<n>::level_type,
> >
> > date_time_system_policies::level_unit_types::get<n-1>::level_type,
> >                                                            ...
> >
> > date_time_system_policies::level_unit_types::get<level_id>::level_type )
> >
> >
> > Then we need one generic iterator through level.
> > Some generic io support.
> > There may be another level of generality that provide current
separation.

we could have
template<date_system,time_system<date_system> >
combining_date_time_system

> > Also we need some generic support for conversions.

template<orig_date_time_system,target_date_time_system>
target_date_time_system::date convert( orig_date_time_system::date )

>
> I'm not following here....
>
> > 2. I/O
> > I/O functionality supplied is very inflexible. It should be completely
> > managed by some user supplied (with some defaults) format string.
> > date_time_system_policies could assign specific letter to each level and
> > that user could define arbitrary formats. Also to/from_string interface
is
> > not acceptable. It should be iostream based one.
>
> I'm sure no matter what is done someone won't be happy with the I/O.  I
specifically
> didn't want to write a 'format string' capability.  This is a complex job
that
> would consume a great deal of time.  I would be happy to incorporate this
if
> someone else wants to take it on. As for inflexible, you are always free
> to extract the elements of a date-time and write your own formatting
routines.

I know that absence of custom format make this library unusable for me. One
of the application is a timestamp of  logging entry. Output format is
specified by logging library user so I need to be able to specify it either.
And I do not want to reimplement it myself.

>
> >   b. fix naming conventions,
>
> Such as?

name_ -> m_name

> >   f. examples should include using <> instead of ""
>
> Disagree.  I subscribe to the <> for std library only camp....

See other sources in boost.

> > 7. time_iterator and date_iterator
> > a. time_iterator should use iterator_adaptor
> > b. date_iterator should use iterator_adaptor and should not be using
virtual
> > functions, really should be one type
>
> You are correct that these should use iterator_adaptors -- I haven't had a
> chance to look at this yet.  The problem is that date_iterator is really
> solving a different problem.  It is allowing the user to plug-in a
calculation
> functor so that it can do things like figure adjust for the end of months
> appropriately.  So maybe it needs a different name like logical_iterator.

why time_iterator does not need such functor

> > 9. Misc.
> > c_local_time_adjustor, local_time_adjustor: does not seems to belong to
> > generic framework. probably should be moved in conversions subsystem.
> > day_clock, second_clock : does not seems to belong to generic framework.
> > probably should be moved in conversions posix subsystem.
>
> No. These could be used for other date-time systems.

time.h. Is it part of generic framework? Probably on different level.

> > 10. Compilation on MSVC issued following warnings:
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(27) :
warning
> > C4244: 'return' : conversion from 'unsigned long' to 'short', possible
loss
> > of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(58) :
warning
> > C4244: 'initializing' : conversion from 'unsigned long' to 'unsigned
short',
> > possible loss of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(59) :
warning
> > C4244: 'initializing' : conversion from 'unsigned long' to 'unsigned
short',
> > possible loss of data
> > \gdtl_057_boost\boost\gdtl\gregorian\gregorian_calendar.ipp(63) :
warning
> > C4244: 'argument' : conversion from 'unsigned long' to 'unsigned short',
> > possible loss of data
>
> These are acceptable.  I suppose we should try to suppress them.

They look strange why do you define local variable long if return type is
short?

> Jeff

Gennadiy