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