Skip to main content
Sign in
Snippets Groups Projects

Commits · 855be47a02e68bf9217ef8ab79dbd94ddc3298f1

  1. Jun 02, 2022
  2. Jun 01, 2022
  3. May 31, 2022
  4. May 30, 2022
  5. May 29, 2022
  6. May 28, 2022
  7. May 27, 2022
  8. May 25, 2022
  9. May 24, 2022
  10. May 23, 2022
  11. May 21, 2022
  12. May 20, 2022
  13. May 19, 2022
  14. May 18, 2022
  15. May 18, 2022
  16. May 17, 2022
  17. May 16, 2022
  18. May 14, 2022
    • Miss Islington (bot)'s avatar
      Check result of utc_to_seconds and skip fold probe in pure Python (GH-91582) · 36d42e70
      Miss Islington (bot) authored
      
      
      The `utc_to_seconds` call can fail, here's a minimal reproducer on
      Linux:
      
      TZ=UTC python -c "from datetime import *; datetime.fromtimestamp(253402300799 + 1)"
      
      The old behavior still raised an error in a similar way, but only
      because subsequent calculations happened to fail as well. Better to fail
      fast.
      
      This also refactors the tests to split out the `fromtimestamp` and
      `utcfromtimestamp` tests, and to get us closer to the actual desired
      limits of the functions. As part of this, we also changed the way we
      detect platforms where the same limits don't necessarily apply (e.g.
      Windows).
      
      As part of refactoring the tests to hit this condition explicitly (even
      though the user-facing behvior doesn't change in any way we plan to
      guarantee), I noticed that there was a difference in the places that
      `datetime.utcfromtimestamp` fails in the C and pure Python versions, which
      was fixed by skipping the "probe for fold" logic for UTC specifically —
      since UTC doesn't have any folds or gaps, we were never going to find a
      fold value anyway. This should prevent some failures in the pure python
      `utcfromtimestamp` method on timestamps close to 0001-01-01.
      
      There are two separate news entries for this because one is a
      potentially user-facing change, the other is an internal code
      correctness change that, if anything, changes some error messages. The
      two happen to be coupled because of the test refactoring, but they are
      probably best thought of as independent changes.
      
      Fixes GH-91581
      (cherry picked from commit 83c0247d)
      
      Co-authored-by: default avatarPaul Ganssle <1377457+pganssle@users.noreply.github.com>
      Unverified
      36d42e70
  19. May 13, 2022
  20. May 12, 2022
  21. May 11, 2022
  22. May 10, 2022
  23. May 09, 2022
  24. May 08, 2022
  25. May 07, 2022
Loading