Limits of automatic timezone conversion in DRF DateTimeField

Goal: Allow Django REST Framework to automatically adjust DateTimeField output to the client's local timezone using request information, eliminating the need for custom renderers or parsers.

Currently, when USE_TZ=True DRF converts aware datetimes to the project's TIME_ZONE; when USE_TZ=False it returns values unchanged, and there is no built‑in mechanism to honor a client‑specific zone supplied via headers or query parameters.

The unresolved design decision is whether DRF should introduce a global setting, a field‑level argument, or rely on middleware to enable client‑zone conversion, and how this would interact with naive versus aware datetime values and daylight‑saving transitions.

Should DRF add a global setting to enable client‑zone conversion? Should DateTimeField accept a timezone argument? What impact would this have on existing naive‑aware handling and backward compatibility?