RE: [boost] [date_time] improvements

From: Jeff Garland (jeff_at_[hidden])
Date: 2003-08-06 08:52:26

John -

Sorry to be slow on this reply...

John Torjo wrote:
> > > [1]
> > > unary operator-(time_iterator).
> > > Example: -hours(24) instead of hours(-24).
> > > (seems more straightforward)
> >
> > I see your point, but then don't you have to add all the other
> > operators for consistency?  Not sure that makes sense to do with
> > the iterator.
> >
> 
> I'm sorry I messed up. I wanted it for time_duration :)
> But anyway, unary operator- I think could make some parts of code a little
> more readable. For instance, I had some code where I would use time_iterator
> to go from, lets say, today, to 3 months before.
> 
> I think unary operator- is very easy to implement for time_duration (and
> perhaps date_duration).

Ah, that makes sense -- on the todo list...
 
> > > [2]
> > > Does a *FOUR* functions justify having a jam file?
> > > (greg_month::as_short_string(), greg_month::as_long_string(),
> > >  greg_weekday::as_short_string(), greg_weekday::as_long_string())
> > >
> ... detail omitted...
> I thought a smart compiler could definitely overcome that.
> Something like, a static inline function:
> 
> // Warning: untested code
> static const char* as_short_string( int idx) {
>     static const char * months[] ={ ... };
>     return months[ idx];
> }

Yep, true.

> > localized strings ever gets into the library there will be many more
> > strings (take a look at libs/date_time/test/gregorian/test_facet.cpp).
> > Finally, there may be other functions that eventually will be in the
> > library and not inlined.
> 
> Sure thing. But you haven't convinced me ;)
> Basically, the above could become:
> 
> static const char * default_as_short_string( int idx) {
> ...
> }
> 
> And as for locales, the user can choose the right locale for him, you can
> still have some static functions, like:
> 
> static const char*[] de_short_month_names() {
>     static const char* const
> names[]={"Jan","Feb","Mar","Apr","Mai","Jun","Jul","Aug","Sep","Okt","Nov","
> Dez", "NAM"};
> return names;
> }
> 
> So, if the user wants a "de" locale, you could - behind the scenes -, select
> de_short_month_names(), de_long_month_names(), etc.
> 
> - they could exist in a distinct header, and they would be #included only if
> the user needs them (wants localized information).
> 

Ok, sure.  I can't really see anything wrong with your argument.  That said,
I still don't want to change this lightly.  While this would make life
easier for users, they are already used to the library. If I get rid of it 
and then want/need it back it won't be nice.  So I'll put this on my
to be considered list, ok?
  
> > > As I understood by looking at the docs, fraction actually means
> > > nano-seconds.
> >
> > Not necessarily.  It depends on the resolution the time duration template
> is
> > instantiated with.  For example, there is a second option that many people
> use
> 
> In that case, I'm confused ;-)
> There should be more info in the docs, I think.

Yep, that's for sure. 
 
> > which only provides microsecond duration resolution, but only requires a
> > single 64 bit integer to represent a time value.  The bottom line is that
> > fractional seconds is a count of the number of fractional seconds at the
> > given resolution.
> 
> Maybe still, for simplicity you could have a time_duration::nanoseconds()
> function.

I agree this would be nice. Of course, I think this will need to fail
compilation if the resolution doesn't support nanoseconds.

> Also, now that I come to think of it :), the following functions would come
> in handy:
> 
> time_duration::total_hours() - the number of hours (ignoring mins, secs,
> etc.)

Don't see how this would be different from the current method.

> time_duration::total_mins() - the total number of minutes (hours*60 +
> minutes() )
> time_duration::total_secs() - you get the idea.
> 
> (of course they can be computed, but it's more error prone)

Yep, these would be handy -- on the list...

Jeff