Re: [boost] [date_time] improvements

From: John Torjo (john.lists_at_[hidden])
Date: 2003-08-04 11:08:39

Hi Jeff,
>
> > Told you I'd come back for more ;)
> > Here are some more improvements I would consider useful:
> >
> > [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).

> > [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())
> >
> > They could definitely be made static or something.
> > (or the user could be given a choice - using the date_time from a
> > .jam-generated
> >  dynamic link library, or directly)
>
> Yes, to avoid multiple definitions of the said strings without having
> to recreate them every time a date is formatted.  Also, if a set of

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];
}

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

>
> BTW, my original intent was to make much more of the library 'inline
> swappable'. That is, by flipping a compile switch large chunks of the
> library could either be inline or in the library -- whichever was
> better for the user's performance / space tradeoff.  I've let this
> slide for now as the way I did it was a pain for users and there are
> more important issues at the moment...

Ok.

>
> > [3]
> > I've been recently involved in a project that used to use raw time_t's.
> > A conversion to/from time_t would come in very handy.
> > (at least one way would be enough).
> > I've created such a function:
> >
> > #include <boost/date_time/posix_time/posix_time.hpp>
> >
> > // converts raw time to cool ptime structure
> > inline boost::posix_time::ptime rawtime_to_ptime( time_t raw) {
> >     using namespace boost::posix_time;
> >     using namespace boost::gregorian;
> >
> >     tm details = *localtime( &raw);
> >     date day( details.tm_year + 1900, details.tm_mon + Jan,
> > details.tm_mday);
> >     time_duration offset( details.tm_hour, details.tm_min,
> > details.tm_sec, 0);    return ptime( day, offset); }
> >
> > pretty simple and straightforward, I think.
>
> I agree, this is on the todo list to add to the library. See
> below for why it isn't already.  I think I would write it like
> this, however:
>
> file://Warning -- off the top of my head untested code (but should work)!
> file://in boost::posix_time namespace
> posix_time from_time_t(time_t t) {
>   using namespace boost::gregorian;
>   return ptime(date(1970,1,1), seconds(t));
> }

Yes, I think your is much simpler ;)
It never crossed my mind - cool indeed!

>
>
> > 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.

> 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.

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

>
> > [7]
> > I think a wrapper like I've attached would be pretty useful for dealing
> > with time values - mainly for testing/debugging.
> > [...]
>
> The reason that I didn't put any time_t related interfaces into
> the library is that I wanted to encourage people away from using
> 'under-abstracted clock-hardware-limited' time representations
> in code.  I suspect you may have spent many hours, as I have,

True.

> debugging errors related to the use of time_t.  I mean, time_t
> is 1/1/1970 0:0:0, right?  Oops, minor point, I mean
> UTC 1/1/1970 0:0:0.  Was that time_t really a time value or
> was it a time duration?  Hard to tell without reading (the
> hopefully consistent) code...
>
> So, my stance on it has been to encourage people to use the
> library and abandon time_t, period.  With a good compiler
> (and perhaps some enhancement) the library should be almost
> as efficient as using time_t. And I really haven't been
> asked much about time_t support. However, I realize this is not
> viable for some projects with large legacy code bases to just

That was my only reason :)

> convert across the board.  Hence I can see the need for the
> from_time_t function, as a bridge between legacy code.
>
> As for your wrapper, I think you are addressing a more general
> topic of layering a debug wrapper around a simple type.  Certainly

True.

> can be a useful technique.  That said, if you have the opportunity
> to modify the source why not just convert to using the library?

Well, not such a good idea - this is because on the server side, I have a DB
that keeps some table fields as time_t values - it would be WAY TOO MUCH
to do.

> It will give you more streaming options than the wrapper class
> without having to write all that code.

Anyway, the code I've sent could be modified to work with your ptime (date,
etc.) as well, since the same problem occurs with your code as well.

When debugging, you see a 'ticks' value - but it's kind of hard to know the
time it represents.

I'm not sure when I'll have some time to do this.

>
> Thanks for the suggestions.
>
Any time ;)

Best,
John