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 `\/\/