Repository navigation
datetimes and dates are not substitutable but mypy thinks they are #9015
Description
Note: if you are reporting a wrong signature of a function or a class in
the standard library, then the typeshed tracker is better suited
for this report: https://github.com/python/typeshed/issues
I tried that first ;-) python/typeshed#3805
Please provide more information to help us understand the issue:
- Are you reporting a bug, or opening a feature request?
This is a bug in the system overall but probably a feature request in mypy itself.
- Please insert below the code you are checking with mypy,
or a mock-up repro if the source is private. We would appreciate
if you try to simplify your case to a minimal repro.
from datetime import date, datetime
if datetime.now() < date.today():
print("that's a surprise!")- What is the actual behavior/output?
No error!
- What is the behavior/output you expect?
A warning, since at runtime I get TypeError: can't compare datetime.datetime to datetime.date.
- What are the versions of mypy and Python you are using?
0.770, 3.8.2
- Do you see the same issue after installing mypy from Git master?
Yes.
- What are the mypy flags you are using? (For example --strict-optional)
python_version=3.8
incremental=True
follow_imports=normal
warn_redundant_casts=True
warn_unused_ignores=True
strict_optional=True
strict_equality=True
no_implicit_optional=True
disallow_untyped_defs=True
disallow_any_generics=True
Activity
JukkaL commentedon Jun 19, 2020
LSP violations are generally tricky. Some of them are fairly benign and rarely cause issues, but others can be painful.
As typeshed includes the subclass relationship present in the implementation, current mypy behavior is arguably "correct". However, I can imagine a way to deal with this in mypy: introduce optional subtype checks that would complain about code that relies on subtyping relationships that are not safe, such as
datetimevsdate. Mypy would maintain a set of known unsafe subtyping relationships, including cases where a class is a subclass of another class but shouldn't be treated as a subtype. This could also be used for things like warning aboutstrused asIterable[str].m-aciek commentedon Jul 5, 2023
Sharing a workaround typing library created by @glyph: https://pypi.org/project/datetype/. Found on StackOverflow.
glyph commentedon Jul 7, 2023
Thanks @m-aciek, I forgot to link it directly from here :)
m-aciek commentedon Sep 17, 2025
Another workaround is to use
datetimeexclusively and use its instances to mark dates (with 00:00 time). This way we preventTypeErrors in runtime when comparing objects.m-aciek commentedon Jan 20, 2026
The case of
str/Iterable[str]is being addressed separately: #20577. Another unsafe subtype relation isint/bool. I couldn't find more in the standard library.I've created a pull request that addresses the check described above, but I wonder if from mypy design perspective there shouldn't be separate flags for each of such relations, for a better control. Please advise. Thank you.
wyattscarpenter commentedon Jan 20, 2026
Is int/bool unsafe? I thought it was just unexpected by people, not unsafe per se. Regardless, related: #8363
m-aciek commentedon Jan 21, 2026
It is not (as) unsafe as datatime/date is. Though in my opinion it's the same category as str/Iterable[str], being unsafe through potential unexpectance.
Thank you for pointing it out. With str/Iterable[str] and int/bool cases being handled separately, with dedicated mypy codes, I'm more inclined to propose a code dedicated only to datetime/date case. I hesitate between
strict-dateorsafe-datetime(are there better candidates? 🤔). I lean towards the second one.Detect unsafe datetime/date operators