New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTimeField should be able to keep original timezone info #6140
Comments
Ref #5435 and related. |
to me not being able to store timezone is like losing data as an event happens in a specific timezone. This could be stored in an all in one fashion but limitations imply saving event timezone elsewhere |
Agreed, this causes data loss by converting the timestamp into the timezone of the server. To expand on the issue, consider the deserialisation case:
This gives me:
But I would expect something more like:
These are equal, but the latter has preserved the submitted timezone information, which might be important. |
I believe this would be a nice thing to have... but I suspect the implementation will not be possible out of the box. |
It looks like that is case, yes. But all supported versions of Postgres support a timestamp with timezone type at no extra cost compared to a regular timestamp. I have a feeling Django has this behaviour to support other DBs that don't support storing the timezone. In any case, it does look like an upstream issue rather than a DRF issue. Edit: Turns out it's postgres itself turning the timestamp into UTC. The TIMESTAMP WITH TIME ZONE type merely accepts a timestamp with timezone, but stores it internally as UTC and forgets the offset that was provided. For other DBs Django does this itself. After some toying around seeing if this is fixable I've realised that the best way to solve the problem here is to store the Olson time zone (not just the offset) in its own field with the UTC timestamp. I doubt this could realistically be abstracted in either Django or DRF given the flexibility of the |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Checklist
master
branch of Django REST framework.Steps to reproduce / Actual behavior
DRF's
DateTimeField
has no option to keep adatetime
's original timezone information during serialization/deserialization. Here a serialization example:USE_TZ = True
andTIME_ZONE = "UTC"
.datetime
object:dt = datetime.datetime(2018, 9, 4, 7, 30, tzinfo=<DstTzInfo 'Europe/Berlin' CEST+2:00:00 DST>)
.serializers.DateTimeField().to_representation(dt)
This yields
'2018-09-04T05:30:00Z'
which represents the datetime in the UTC timezone.Expected behavior
The serialized datetime is correct, however, does not contain any information about the original timezone. DRF's
DateTimeField
should provide an option to preserve this timezone info by instead serializing to:'2018-09-04T07:30:00+02:00'
.Why?
While the returned string is correct, there are use cases in which a frontend (API consumer) might want to display the datetime in the timezone it was originally in. For example, a flight ticket search engine generally displays any datetimes in the local timezone of the airport. So instead of displaying the departure time of a flight in UTC it generally displays it in the timezone of the airport. This is however not possible with the current implementation of
DateTimeField
.Possible Solution
Would the maintainers be open to a PR that adds an option to the
DateTimeField
that would allow it to deserialize / serialize datetimes while keeping their original datetime? I can go into depth about other use cases and possible implementations, however, I would like to first know if this idea is welcome in general.This problem was already mentioned in #3732 and generally well received ("I’m really happy to take a PR on this."), however, the issue originally addressed another problem and was subsequently closed before the issue I am mentioning here was addressed.
The text was updated successfully, but these errors were encountered: