Re: [Boost-users] [datetime] Parametrization of class datetime.

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-25 00:25:53

Seweryn Habdank-Wojewódzki wrote:
> Hi
> 
> Beth Jacobson wrote:
> 
> 
>>ticks()/ticks_per_second() will give you the correct number of seconds.
> 
> 
> I know it.
>  
> 
>>I think Seweryn was talking about this:
>>long total_seconds()
>>^^^^
> 
> 
> Yes. Exactly.
>  
> 
>>You can have a time duration of 200 years, but the number of seconds in
>>200 years is too large to fit in a long, so the total_seconds() function
>>won't work.
> 
> 
> Exactly.
>  
> 
>>According to the doc, ticks() returns a boost::int64_t. Couldn't
>>total_seconds(), total_milliseconds(), etc. do the same?
> 
> Yes. So the question is if there is any possibility to parametrize it with
> other tyle bigger than long.
>
Sorry for the delay on the reply.  I didn't understand the issue from 
your first mail. Yes, it can be trivially done.  'long' is really just 
what the docs say.  The code is actually in terms of a template that 
defaults to boost::int32_t.  This can be trivially changed by as follows:

Add boost::int64_t as the last parameter in templates in 
date_time/time_resolution_traits.hpp::133 and ::134  So new is:

   typedef time_resolution_traits<time_resolution_traits_adapted64_impl, 
micro, 1000000, 6, boost::int64_t > micro_res;
//                 ^^^^^^^^^^^^^^
   typedef time_resolution_traits<time_resolution_traits_adapted64_impl, 
nano,  1000000000, 9, boost::int64_t > nano_res;
//                    ^^^^^^^^^^^^^^

Of course, if you change it to BigInt that should work as well.  But 
honestly, if you are going the BitInt route there are a few other 
parameters you would want to update to get more consistent behavior.

> In fact there is no bignum library in boost. Probably reason is because GMP is
> very good. But sometimes there is important to calculate time distances bigger
> than numeric_limits<long>::max()/(365*24*60*60) what is more less 68 years.

There is a bitInt in the sandbox by Ron Garcia which has the option to 
wrap around gmp -- not sure if it will ever be submitted.

In any case, the design of date_time supports this flexibility, but a 
configuration using a BigInt has been tried.  Half the reason I wrote 
the library was that I was frustrated with date_time systems with a 
fixed internal representation. So many of them fix the representation at 
some arbitrarily sized number -- like 32 bits.  Unfortunately, one day 
you need something bigger -- oh, sorry library rewrite. It's a classic 
example of why OO fails in some cases -- a supposedly internal design 
decision that ends up dramtically limiting the user options.  As it is, 
the library is routinely built and tested with 2 variations: 96 bit 
internal times and 64 bit internal times.  Other options are just a few 
keystrokes away.

If you have a real use case where this would be used I'd be willing to 
work thru how to set it up.  There may be some troubles with infinite 
precision numbers and how they interact with the 
infinity/not-a-date-time handling, but otherwise it shouldn't be too hard.

Jeff