Who can explain it to me?
Using DateTimeStrFormat("%Y-%m-%d %H:%M:%S", NUMBER)
0x7FFFFFFFFFFFFFFF (9223372036854775807, maximum of int64_t) prints: 1969-12-31 23:59:59
0x7FFFFFFFFFFFFFFF + 1 prints: 1970-01-01 00:00:00
0xFFFFFFFFFFFFFFFF prints: 1969-12-31 23:59:59
0 prints: 1970-01-01 00:00:00
@jonasschnelli Are you sure that we suffer from that problem or is it something different here?
When the int64 0x7FFFFFFFFFFFFFFF is converted to a 32-bit time_t, it becomes 0xFFFFFFFF, which is -1. so you're really passing -1. 1 second before Epoch is 1969-12-31 23:59:59.
I really had the impression Bitcoin Core would be using real 64 bit values for time or is that a Boost limitation currently? My compiler is a x64 one (MinGW).
We use int64_t for time internally, but that doesn't mean that e.g. the OS or dependency libraries for time formatting and parsing can handle the full range.
E.g. boost::posix_time::from_time_t in this case takes a std::time_t, as it says on the tin.
So in theory if your build environment has a 64-bit std::time_t (this is the case here), it should handle 0x7FFFFFFFFFFFFFFFLL.
But I get the same result. So this may be a bug in boost, or somewhere else down the line.
Is it this one https://svn.boost.org/trac/boost/ticket/4543?
Huu.. opened 4 years ago, last edit 3 years ago.
From what I can tell, this has been fixed in date_time (Boost ticket 4543), and the changes have been merged into Boost as part of 1.64.0, which we are now using.
@meshcollider I don’t think this will actually be fixed until Boost 1.67.0?
Can this be closed? We're not using DateTimeStrFormat after #12973