gh-88994: Change datetime.now to half-even rounding for consistency with datetime.fromtimestamp.#134258
gh-88994: Change datetime.now to half-even rounding for consistency with datetime.fromtimestamp.#134258vstinner merged 5 commits intopython:mainfrom
datetime.now to half-even rounding for consistency with datetime.fromtimestamp.#134258Conversation
…etime.fromtimestamp`.
|
All commit authors signed the Contributor License Agreement. |
|
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
|
Would you mind to sign the CLA? |
|
You should add a NEWS entry to document your change, see https://devguide.python.org/ which explains how to add one. |
| @@ -0,0 +1,2 @@ | |||
| Change :func:`datetime.datetime.now` to half-even rounding for | |||
| consistency with :func:`datetime.datetime.fromtimestamp`. | |||
There was a problem hiding this comment.
If you want you can also add "Patch by (Your name however you want it rendered)." here.
I am unable to reproduce such success on Linux? |
Co-authored-by: Stan Ulbrych <[email protected]>
|
Merged, thank you for your contribution! |
|
@vstinner out of curiosity does it work for you, it's hard to believe it's somehow windows only. |
Using a debug build, I failed to reproduce the issue. I trust the code, I know what it does :-) |
|
Huh; I can still reproduce the problem but only on a release Linux build. I'm investigating to see if there's something else I can do to ensure consistency there. |
time.time() uses float which is not great in terms of accuracy. Using time.time_ns() would be better. Sadly, there is no "fromtimestampns()" function. |
…ython#134258) Change `datetime.datetime.now` to half-even rounding for consistency with `datetime.fromtimestamp`.
…ython#134258) Change `datetime.datetime.now` to half-even rounding for consistency with `datetime.fromtimestamp`.
Resolves #88994 where, on platforms with nanosecond resolution system clocks (such as Windows), the truncation within
datetime.nowcould cause time to appear to go backwards by 1 microsecond betweendatetime.datetime.fromtimestamp(time.time(), None)anddatetime.datetime.now().As suggested by @pganssle, not adding a test that would probably be flaky since it would involve comparing the results of multiple reads of the system clock. Verified manually that the following quickly fails the assert on Windows but passes with this commit: