Limits of automatic timezone conversion in DRF DateTimeField

No — DRF should not add a global setting that rewrites DateTimeField output into a client-supplied timezone. If an opt-in is added at all, a new field-level argument is the safer shape, and it must not overload the existing default_timezone. The underlying reason is simple: a client zone is request context, and a plain serializer field has no request.

What DRF actually does today

DateTimeField.to_representation serializes an aware datetime as ISO-8601 with its offset, commonly rendering UTC as Z. It does not call timezone.localtime() against settings.TIME_ZONE. USE_TZ mainly governs how naive input is interpreted and how Django's own current-timezone machinery behaves; it is not a switch that makes DRF output client-local.

The one timezone-related field argument that exists, default_timezone, affects to_internal_value for naive input — not output. So a header or query parameter cannot influence serialization through any built-in hook.

Why a header or query parameter cannot reach the field

To honor X-Client-Timezone or ?tz=, something must read the request and pass it down. The realistic options are: a custom field that reads self.context['request']; a SerializerMethodField; or middleware that activates a zone plus a custom field that calls timezone.localtime. Middleware alone changes Django rendering and naive parsing, not DRF's ISO output.

Backward compatibility and caching

Request-dependent output means the same resource returns different offsets to different clients. That can break HTTP caching, ETags, log correlation, and exact-string comparisons in tests or consumers. A global switch is risky even defaulted off, because it invites accidental activation; an explicit per-field opt-in preserves current behavior by default.

Naive values and DST

Converting an aware instant to a client zone is unambiguous. Parsing a naive client wall-clock time is the dangerous half, especially for ambiguous or nonexistent local times around DST transitions. Validate zone names against the IANA database, keep storage and transport in aware UTC, and state clearly whether any new argument converts aware values only or also reinterprets naive input.

A conservative design if server-side local rendering is required

• Keep API payloads in aware UTC ISO-8601 and let clients render local time.
• If needed, add a custom field that reads the request, validates the zone, and calls timezone.localtime(value, zone) for aware values only.
• Leave naive values untouched or reject them explicitly.
• Do not expect middleware timezone activation to change DRF output by itself.

Verification

from datetime import datetime, timezone as dt_timezone
from rest_framework import serializers

class S(serializers.Serializer):
    when = serializers.DateTimeField()

value = datetime(2026, 10, 15, 20, 48, 48, tzinfo=dt_timezone.utc)
print(S({"when": value}).data)  # expect ISO-8601 with offset/Z

Repeat with USE_TZ=False and with a different activated timezone. If the string does not change, output conversion is not happening. Post a naive string with and without default_timezone to observe the input side.

Version note: this describes DRF 3.x with Django 4.2/5.x. Formatting and timezone handling are version-sensitive, so pin expectations with tests rather than assuming.