#24281: auto_now & auto_now_add ignore TIME_ZONE / USE_TZ settings for DateField
-------------------------------------+-------------------------------------
Reporter: djbug | Owner: nobody
Type: Bug | Status: new
Component: | Version: master
Internationalization |
Severity: Normal | Resolution:
Keywords: timezone | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by carljm):
Replying to [comment:8 djbug]:
> This makes me think that if `USE_TZ` is True, the date should be grabbed
from the UTC datetime.
That sentence in the docs should probably be updated for clarity to be
specifically discussing "datetimes", not "dates and times".
It's good practice to store -datetimes- in the database as UTC, simply for
consistency. That way you always know unambiguously what you're getting
from the database, and a UTC datetime can always be converted to whatever
timezone you need to display it in.
Dates and times are fundamentally different from datetimes -- they don't
have a timezone, and they can't be converted into another timezone for
display. (Well, a time can sort of be converted to a different timezone by
just adding/subtracting an offset, if you're willing to be completely
naive about DST, but that's generally a bad idea.) So the best-practice
regarding datetimes does not apply to dates or times - it's not
necessarily correct to just "always store in UTC" because they can't be
converted from UTC to anything else, so what you should store in the
database is "whatever is correct for your application." For the specific
case of a `DateField` with `auto_now(_add)`, what is correct really
depends on the purpose of the field. If the server wants to consistently
privately track the created-date for objects in a way that is comparable
to each other, it may make sense to use "creation date in UTC", or in the
server timezone (though really for this case I don't know why you'd use a
`DateField` rather than a full timestamp). If it's a field meant for user
display, then it probably makes more sense to use "today's date in the
user's local timezone," otherwise it will appear to the user to give the
wrong date sometimes.
My conclusions from all this:
- Unless you really know that you need a `DateField`, you should probably
consider just using a `DateTimeField` instead, and convert to date for
display only. Storing a `DateField` in the database is choosing to store a
lossy and ambiguous format over a precise and unambiguous one. (Even if
you need to compare dates in the database as dates, with modern Django
lookups should make that possible if you store datetimes.)
- `DateField(auto_now[_add])` is basically ambiguous when it comes to
timezones - it would be better to be explicit with a default value that
does what you expect regarding timezones. This might be a reason to
consider deprecating `auto_now(_add)` for `DateField` only.
- Short of that, although it may be easier to imagine cases where you'd
want "date in user's timezone" rather than "date in a way that's
comparable across all objects", we don't really know which the user wants,
and so we should default to not changing the current behavior. For
instance, I could imagine someone using `DateField(auto_now_add=True)` for
easily grouping objects by the day they were created on. This use case
depends on the same timezone being used to determine the created-date for
all objects created, so the proposal to switch to date-in-localtime would
break it.
--
Ticket URL: <https://code.djangoproject.com/ticket/24281#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/063.406cead802e814db8e8e75dac3ca291b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
