Opened 46 minutes ago
#37104 new Cleanup/optimization
Naive timestamps used in migrations should reference the same timezone
| Reported by: | James Beith | Owned by: | |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | 6.0 |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
When creating a migration there are two reference timestamps; one in the filename (e.g. 0002_auto_20260518_0601.py) and one in the source header (e.g. # Generated by Django 6.0.5 on 2026-05-18 05:01).
The filename is created here, using current local date and time (from Python's runtime perspective), in this example "Europe/London".
The source header is created here, using UTC if settings.USE_TZ, otherwise current local date and time similar to filename.
This can lead to different (naive) timestamps used in the filename and source header. Is there any reason why they shouldn't be the same?
In terms of a fix, I think the change might be to have the filename call the Django timezone util instead of straight to Python's now classmethod.