#23832: Storage API should provide a timezone aware approach
-------------------------------------+-------------------------------------
Reporter: jaylett | Owner:
Type: New feature | Status: new
Component: File | Version: 1.7
uploads/storage | Resolution:
Severity: Normal | Triage Stage:
Keywords: | Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by freakboy3742):
I've just taken a look at this; I think the answer might be a lot simpler
that I originally thought.
`getatime`, `getmtime` and `getctime` all return seconds past epoch -
which *has* a timezone; we're just not using that information. So we're in
a position to construct a non-naïve timestamp - we're just not doing so.
If we make the call to `datetime.fromtimestamp` and immediately cast to
UTC, the timestamp will be correct and non-naïve.
So - at the very least, the timezone guessing in `_possibly_make_required`
isn't required.
However, what's the concern about backwards compatibility here? Is there
any reason that changing those methods to return non-naive timezones will
cause a problem?
--
Ticket URL: <https://code.djangoproject.com/ticket/23832#comment:6>
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/065.28828b67a8cc8442b24b4600fee94fe3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
