Different libc implementations have different behavior when presented with trailing % in strftime strings. To make test_strftime_trailing_percent more portable, compare the output of datetime.strftime directly to that of time.strftime rather than hardcoding.
(cherry picked from commit f2173ae38f)
Co-authored-by: Benjamin Peterson <benjamin@python.org>
This fixes an inconsistency between the Python and C implementations of
the datetime module. The pure python version of the code was not
accepting offsets greater than 23:59 but less than 24:00. This is an
accidental legacy of the original implementation, which was put in place
before tzinfo allowed sub-minute time zone offsets.
GH-14878
(cherry picked from commit 92c7e30adf)
There was a discrepancy between the Python and C implementations.
Add singletons ALWAYS_EQ, LARGEST and SMALLEST in test.support
to test mixed type comparison.
(cherry picked from commit 17e52649c0)
Returns NotImplemented for timedelta and time in __eq__ for different types in Python implementation, which matches the C implementation.
This also adds tests to enforce that these objects will fall back to the right hand side's __eq__ and/or __ne__ implementation.
[bpo-37579](https://bugs.python.org/issue37579)
(cherry picked from commit e6b46aafad)
Co-authored-by: Xtreak <tir.karthi@gmail.com>
https://bugs.python.org/issue37579
For datetime.datetime.strptime(), the leading zero for some two-digit formats is optional.
This adds a footnote to the strftime/strptime documentation to reflect this fact, and adds some tests to ensure that it is true.
bpo-34903
(cherry picked from commit 6b9c204ee7)
Co-authored-by: Mike Gleen <mike.gleen@gmail.com>
Previously, calling the strftime() method on a datetime object with a
trailing '%' in the format string would result in an exception. However,
this only occured when the datetime C module was being used; the python
implementation did not match this behavior. Datetime is now PEP-399
compliant, and will not throw an exception on a trailing '%'.
(cherry picked from commit 454b3d4ea2)
Co-authored-by: MichaelSaah <mike.saah@gmail.com>
Fixes assertion failures in _datetimemodule.c
introduced in the previous fix (see bpo-31752).
Rather of trying to handle an int subclass as exact int,
let it to use overridden special methods, but check the
result of divmod().
(cherry picked from commit 3ec0f49516)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* Use _PyUnicode_Copy in sanitize_isoformat_str
* Use repr in fromisoformat error message
This reverses commit 67b74a98b2 per Serhiy Storchaka's suggestion:
I suggested to use %R in the error message because including the raw
string can be confusing in the case of empty string, or string
containing trailing whitespaces, invisible or unprintable characters.
We agree that it is better to change both the C and pure Python versions
to use repr.
* Retain non-sanitized dtstr for error printing
This does not create an extra string, it just holds on to a reference to
the original input string for purposes of creating the error message.
* PEP 7 fixes to from_isoformat
* Separate handling of Unicode and other errors
In the initial implementation, errors other than encoding errors would
both raise an error indicating an invalid format, which would not be
true for errors like MemoryError.
* Drop needs_decref from _sanitize_isoformat_str
Instead _sanitize_isoformat_str returns a new reference, even to the
original string.
(cherry picked from commit 3df85404d4)
Co-authored-by: Paul Ganssle <pganssle@users.noreply.github.com>
The current C implementations **crash** if the input includes a surrogate
Unicode code point, which is not possible to encode in UTF-8.
Important notes:
1. It is possible to pass a non-UTF-8 string as a separator to the
`.isoformat()` methods.
2. The pure-Python `datetime.fromisoformat()` implementation accepts
strings with a surrogate as the separator.
In `datetime.fromisoformat()`, in the special case of non-UTF-8 separators,
this implementation will take a performance hit by making a copy of the
input string and replacing the separator with 'T'.
Co-authored-by: Alexey Izbyshev <izbyshev@ispras.ru>
Co-authored-by: Paul Ganssle <paul@ganssle.io>
(cherry picked from commit 096329f0b2)
Co-authored-by: Paul Ganssle <pganssle@users.noreply.github.com>
On Windows, passing a negative value to local results in an OSError because localtime_s on Windows does not support negative timestamps. Unfortunately this means that fold detection for timestamps between 0 and max_fold_seconds will result in this OSError since we subtract max_fold_seconds from the timestamp to detect a fold. However, since we know there haven't been any folds in the interval [0, max_fold_seconds) in any timezone, we can hackily just forego fold detection for this time range on Windows.
(cherry picked from commit 96d1e69a12)
Co-authored-by: Ammar Askar <ammar_askar@hotmail.com>
A datetime object d is aware if d.tzinfo is not None and
d.tzinfo.utcoffset(d) does not return None. If d.tzinfo is None,
or if d.tzinfo is not None but d.tzinfo.utcoffset(d) returns None,
d is naive.
This commit ensures that instances with non-None d.tzinfo, but
d.tzinfo.utcoffset(d) returning None are treated as naive.
In addition, C acceleration code will raise TypeError if
d.tzinfo.utcoffset(d) returns an object with the type other than
timedelta.
* Updated the documentation.
Assume that the term "naive" is defined elsewhere and remove the
not entirely correct clarification. Thanks, Tim.
(cherry picked from commit 877b23202b)
Co-authored-by: Alexander Belopolsky <abalkin@users.noreply.github.com>
* Added a test case for strftime("%z").
The added test checks a case with UTC offest expressed in an integer
number of seconds.
* Added a test comparing naive and aware datetimes.
Check that a greater than comparison of a naive datetime instance with
an aware one raises a TypeError.
* Test datetime in fold or in gap comparison both ways.
(cherry picked from commit 4c3e39f61c)
Co-authored-by: Alexander Belopolsky <abalkin@users.noreply.github.com>
Fix typos found by codespell in docs, docstrings, and comments.
(cherry picked from commit c3d9508ff2)
Co-authored-by: Leo Arias <leo.arias@canonical.com>
* Add timezone to datetime C API
* Add documentation for timezone C API macros
* Add dedicated tests for datetime type check macros
* Remove superfluous C API test
* Drop support for TimeZoneType in datetime C API
* Expose UTC singleton to the datetime C API
* Update datetime C-API documentation to include links
* Add reference count information for timezone constructors
* Add tests for date subclass alternate constructors
* Switch over alternate date constructors to fast path
* Switch datetime constructors to fastpath, fix bpo-32404
* Add fast path for datetime in date subclass constructor
* Set fold in constructor in datetime.combine
* Add news entries.
* Closes issue bpo-5288: Allow tzinfo objects with sub-minute offsets.
* bpo-5288: Implemented %z formatting of sub-minute offsets.
* bpo-5288: Removed mentions of the whole minute limitation on TZ offsets.
* bpo-5288: Removed one more mention of the whole minute limitation.
Thanks @csabella!
* Fix a formatting error in the docs
* Addressed review comments.
Thanks, @haypo.
Several 32-bit systems have issues with transitions in the year
2037. This is a bug in the system C library since time_t does not
overflow until 2038, but let's skip tests starting from 2037 to work
around those bugs.
Miss Islington (bot)
Pablo Galindo
Paul Ganssle
Serhiy Storchaka
Xtreak
penguindustin
Riccardo Magliocchetti
Mario Corchero
Oren Milman
Alexander Belopolsky
Utkarsh Upadhyay
Victor Stinner
R David Murray
Raymond Hettinger
Alexander Belopolsky