Re: [boost] [date_time] improvements
> > 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? Sure thing ;) > > > > 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. Not really. If lets say the fractional_seconds are milliseconds, then you should return ticks() * 1000 (I think) > > > 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. It wouldn't ;) Just to be consistent ;) Best, JOhn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [date_time] improvements
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
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [date_time] improvements
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
> >
> > // 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() )
ti
Re: [boost] [date_time] improvements
On Mon, 4 Aug 2003 12:50:36 +0300, John Torjo wrote
> 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.
> [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
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.
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...
> [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
>
> // 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:
//Warning -- off the top of my head untested code (but should work)!
//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));
}
> [4]
> time_duration::fractional_seconds() seems pretty confusing.
Sorry about that...
> 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
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.
> [5]
> In file gregorian_calenar.hpp, you
> #include "gregorian_calendar.ipp"
>
> I think to make it more portable, it should be:
> #include
Yep, that should be fixed.
> [6]
> documentation - does not say if greg_day starts from one or zero
> (from experiments, I realized it starts from one)
> Maybe this is not so important, but was confusing for me at first.
Well, I think greg_day might be a bit under-documented in general. I've
added your comment to the todo list.
> [7]
> I think a wrapper like I've attached would be pretty useful for dealing
> with time values - mainly for testing/debugging.
>
> (as a matter of fact, this simple wrapper helped me a lot catch a
> few bugs from code written by others. all I had to do was replace
> time_t with time_t_wrapper<>)
>
> Short description:
> - this allows writing times (to streams) in a user-friendly manner:
> besides the time_t value, a *word* that shows what the time_t
> value means. - also, reading these values from streams can be done
> using the '>>' operator. The cool thing is that both time_t and
> time_t_wrapper<> values can be read from a stream.
>
> time_t_wrapper<> can be used in two modes:
> - debug mode
> - release mode (time_t_wrapper<> can be as efficient as time_t in release
> mode)
>
> In debug mode, each value contains a user-friendly string
> corresponding to the time_t value.
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,
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 o
