You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This cropped up in testing ZODB (see zopefoundation/ZODB#33), which relies on the particular repr of known TimeStamp objects, but it's not hard to imagine this having implications in many other ways.
Here's a doctest-like example:
First, verify we have access to a C implementation:
>>>importsys>>>sys.version'2.7.9 (default, Dec 13 2014, 15:13:49) \n[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)]'>>>importpersistent.TimeStamp>>>persistent.TimeStamp.TimeStamp<built-infunctionTimeStamp>
Next, set up a constant time (this exact floating point value and timestamp come from ZODB tests):
This cropped up in testing ZODB (see zopefoundation/ZODB#33), which relies on the particular repr of known TimeStamp objects, but it's not hard to imagine this having implications in many other ways.
Here's a doctest-like example:
First, verify we have access to a C implementation:
Next, set up a constant time (this exact floating point value and timestamp come from ZODB tests):
Create a C and Python TimeStamp:
Not only do they have different reprs and raw values (different in the last character):
They're not even equal to each other, despite having the same input:
To me this seems like a bug. I can try to put together a PR, but I'm not familiar with the code so it might take me awhile.
The text was updated successfully, but these errors were encountered: