Introduction

This error almost always comes from confusing the datetime module with the datetime class inside that module. strptime exists, but it is a class method on datetime.datetime, so the fix is usually the right import statement or the right qualified name.

Why the Error Happens

Python’s standard library has a module named datetime. Inside that module there is also a class named datetime.

That means these two imports are not equivalent:

import datetime
from datetime import datetime

With the first form, you imported the module. With the second form, you imported the class.

So the correct call depends on which style you used.

Use the Matching Call Syntax

If you import the class directly, call datetime.strptime(...).

1from datetime import datetime
2
3value = datetime.strptime("2026-03-04 12:30", "%Y-%m-%d %H:%M")
4print(value)

If you import the module, call datetime.datetime.strptime(...).

1import datetime
2
3value = datetime.datetime.strptime("2026-03-04 12:30", "%Y-%m-%d %H:%M")
4print(value)

The error appears when those two styles get mixed.

Check for Local Module Shadowing

A second common cause is naming your own file datetime.py. In that case, Python imports your local file instead of the standard library module.

import datetime
print(datetime.__file__)

If the printed path points into your project instead of the standard library location, rename the file and remove cached bytecode.

mv datetime.py datetime_helpers.py
find . -name "__pycache__" -type d -prune -exec rm -rf {} +

After that, rerun the script so Python imports the real library.

Do Not Confuse This With a Format Error

Once the import is fixed, you can still get a different exception if the format string does not match the input. That error is ValueError, not AttributeError.

1from datetime import datetime
2
3try:
4    dt = datetime.strptime("04/03/2026", "%Y-%m-%d")
5    print(dt)
6except ValueError as ex:
7    print("format mismatch:", ex)

This distinction matters because the import problem and the date-format problem happen at different stages.

Centralize Parsing Logic

If your project parses dates in several places, wrap that logic in a small helper. That keeps import style consistent and makes it easier to change formats later.

1from datetime import datetime
2
3FORMATS = ["%Y-%m-%d", "%Y/%m/%d"]
4
5
6def parse_date(text: str) -> datetime:
7    for fmt in FORMATS:
8        try:
9            return datetime.strptime(text, fmt)
10        except ValueError:
11            pass
12    raise ValueError(f"unsupported date format: {text}")
13
14print(parse_date("2026/03/04"))

A shared utility also makes tests more focused because parsing behavior is defined in one place.

A Simple Rule for Future Code

The easiest way to avoid this class of bug is to pick one import style for the whole project and stick to it. For example, if a team always writes from datetime import datetime, then every call site consistently uses datetime.strptime(...) and code reviews can spot mistakes quickly.

Consistency matters more than personal preference here. The error is small, but it wastes time because the names look almost identical while referring to different objects.

Common Pitfalls

The biggest mistake is writing import datetime and then calling datetime.strptime(...). That calls the module, not the class.

Another issue is local module shadowing from a file named datetime.py.

A third problem is treating a ValueError from a mismatched format string as if it were the same problem as the missing attribute error.

Summary

• 'strptime belongs to datetime.datetime, not to the module root.'
• 'from datetime import datetime and import datetime require different call syntax.'
• Check for local files named datetime.py if attributes seem to be missing.
• Separate import problems from format-string problems when debugging.
• Put repeated parsing logic into one helper to keep date handling consistent.