[datetime] Parametrization of class datetime.
Hi! I wonder if there is any posibility to change boost::datetime result class eg. long to any bignum class eg. from GMP library or double type. It is important question for calculation distance between let's say 1900 and 2100 and using method eg. total_seconds(). There is no methods like total_minutes(), total_hours(), total_days() and so on, so if I would like to have a distance in days I have to calculate distance in seconds and recalculate it to days, but for big distances total_seconds() exceeded long ranges. Regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/
Seweryn Habdank-Wojewódzki wrote:
Hi!
I wonder if there is any posibility to change boost::datetime result class eg. long to any bignum class eg. from GMP library or double type.
It is important question for calculation distance between let's say 1900 and 2100 and using method eg. total_seconds(). There is no methods like total_minutes(), total_hours(), total_days() and so on, so if I would like to have a distance in days I have to calculate distance in seconds and recalculate it to days, but for big distances total_seconds() exceeded long ranges.
Doubles are explicitly not used to avoid the precision issues in calculations. However, the library is designed with templates that allow exactly this sort of internal representation replacement. And, in fact, the normal internal representations for times use either 64 or 96 bits -- so I believe you're use case is already covered. Have you tried it? Jeff
Hi
Doubles are explicitly not used to avoid the precision issues in calculations.
This is resonable.
However, the library is designed with templates that allow exactly this sort of internal representation replacement. And, in fact, the normal internal representations for times use either 64 or 96 bits -- so I believe you're use case is already covered. Have you tried it?
No. Could you tell me how to use it? And how I could to effectively measure e.g. number of weeks from beginning of the 1900 up to 2100? Best regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/
Jeff Garland wrote:
Seweryn Habdank-Wojewódzki wrote:
Hi!
I wonder if there is any posibility to change boost::datetime result class eg. long to any bignum class eg. from GMP library or double type.
It is important question for calculation distance between let's say 1900 and 2100 and using method eg. total_seconds(). There is no methods like total_minutes(), total_hours(), total_days() and so on, so if I would like to have a distance in days I have to calculate distance in seconds and recalculate it to days, but for big distances total_seconds() exceeded long ranges.
ticks()/ticks_per_second() will give you the correct number of seconds.
Doubles are explicitly not used to avoid the precision issues in calculations. However, the library is designed with templates that allow exactly this sort of internal representation replacement. And, in fact, the normal internal representations for times use either 64 or 96 bits -- so I believe you're use case is already covered. Have you tried it?
Jeff
I think Seweryn was talking about this: long total_seconds() ^^^^ 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. According to the doc, ticks() returns a boost::int64_t. Couldn't total_seconds(), total_milliseconds(), etc. do the same? Regards, Beth
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. 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. Regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/
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
Hi Jeff Garland wrote:
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:
Thanks a lot for explanations. I will try to work with other types and try to include GMP or other BigNums.
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.
I understand.
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.
I will look at them.
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.
Yes it is true. But from other hand there are so many "infinity" calendars, that could be implemented in programs.
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.
Yes I understand this.
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.
Once more thanks, I will work with it. Best regards. -- |\/\/| Seweryn Habdank-Wojewódzki `\/\/
participants (3)
-
Beth Jacobson -
Jeff Garland -
Seweryn Habdank-Wojewódzki