django-cfg 2.3.331__tar.gz → 2.3.332__tar.gz

{django_cfg-2.3.331 → django_cfg-2.3.332}/CHANGELOG.md

@@ -108,6 +108,28 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
     public names import from it as before.
 
 ### Fixed
+
+- **API datetimes were shifted by the visitor's UTC offset while labelled
+  `Z`.** `REST_FRAMEWORK["DATETIME_FORMAT"]` is `%Y-%m-%dT%H:%M:%SZ` (literal
+  `Z`), but DRF converts an aware datetime to the *active* timezone before
+  formatting, and `TimezoneMiddleware` activates the visitor's zone from
+  `X-Timezone` (the generated TS SDK sends it). A visitor at +08:00 got local
+  wall-clock time marked as UTC: `expires_at` 8 hours late, timers firing 8
+  hours late. Plain curl without the header was correct, a browser was not.
+  - Fix: `DateTimeField.to_representation` now renders under
+    `timezone.override(UTC)`. The wire format is unchanged (literal `Z`).
+  - Chosen over a serializer/base-class override because patching DRF's own
+    `DateTimeField` covers plain `serializers.DateTimeField()`, ModelSerializer
+    fields and subclasses with no project changes. It is applied when
+    `django_cfg.middleware.timezone` is imported (that is, whenever the
+    middleware is installed); `AppConfig.ready` is not used because
+    `django_cfg/apps/` shadows `apps.py`, so `ready()` never runs.
+  - Not changed: `TimezoneMiddleware` still activates the zone for templates,
+    admin and ORM-side code. Input parsing is untouched, so a naive datetime
+    in a request body is still read as visitor-local. A field with an explicit
+    `default_timezone=` keeps it.
+  - Visible effect: clients that worked around the shift will now show
+    correct times; clients that did not were showing wrong ones.
 - **A schedule removed from the config no longer keeps firing.** rq-scheduler
   keeps a job until something cancels it. Before this fix a dropped
   `RQScheduleConfig` stayed in Redis, and once its function was deleted it

{django_cfg-2.3.331 → django_cfg-2.3.332}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: django-cfg
-Version: 2.3.331
+Version: 2.3.332
 Summary: Modern Django framework with type-safe Pydantic v2 configuration, Next.js admin integration, and 8 enterprise apps. Replace settings.py with validated models,  90% less code. Production-ready with AI agents, auto-generated TypeScript clients,  and zero-config features.
 Project-URL: Homepage, https://djangocfg.com
 Project-URL: Documentation, https://djangocfg.com

{django_cfg-2.3.331 → django_cfg-2.3.332}/pyproject.toml

@@ -10,7 +10,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "django-cfg"
-version = "2.3.331"
+version = "2.3.332"
 description = "Modern Django framework with type-safe Pydantic v2 configuration, Next.js admin integration,\nand 8 enterprise apps. Replace settings.py with validated models, \n90% less code. Production-ready with AI agents, auto-generated TypeScript clients, \nand zero-config features.\n"
 readme = "README.md"
 keywords = [

{django_cfg-2.3.331 → django_cfg-2.3.332}/src/django_cfg/__init__.py

@@ -32,7 +32,7 @@ Example:
 default_app_config = "django_cfg.apps.DjangoCfgConfig"
 
 # Version information
-__version__ = "2.3.331"
+__version__ = "2.3.332"
 __license__ = "MIT"
 
 # Setup warnings debug early (checks env var only at this point)

{django_cfg-2.3.331 → django_cfg-2.3.332}/src/django_cfg/core/debug/warnings_helper.py

@@ -151,5 +151,7 @@ def setup_warnings_debug(
                 message=pattern
             )
 
-    print(f"🔍 Django-CFG Warnings Debug enabled for: {[c.__name__ for c in categories]}")
-    print(f"   Patterns: {patterns}")
+    # stderr, not stdout: management commands such as `fleet_enroll_token` print machine-readable
+    # output on stdout, and this banner broke pipes and polluted captured values.
+    print(f"🔍 Django-CFG Warnings Debug enabled for: {[c.__name__ for c in categories]}", file=sys.stderr)
+    print(f"   Patterns: {patterns}", file=sys.stderr)

{django_cfg-2.3.331 → django_cfg-2.3.332}/src/django_cfg/middleware/timezone.py

@@ -11,6 +11,10 @@ Persistence: when an authenticated user's timezone differs from what is
 stored on their profile, the field is updated via a single UPDATE query.
 A 24-hour in-process cache (keyed by user_pk + tz string) prevents
 hitting the DB on every request.
+
+API output: DRF datetimes always render in UTC (see
+``django_cfg.startup.drf_datetime_utc``); the active zone still drives
+templates, admin and ORM-side code.
 """
 
 import logging
@@ -20,6 +24,8 @@ from datetime import datetime
 from django.contrib.auth import get_user_model
 from django.utils import timezone as dj_timezone
 
+from django_cfg.startup.drf_datetime_utc import patch_drf_datetime_utc
+
 logger = logging.getLogger(__name__)
 
 # In-process cache: {user_pk: tz_string} — refreshed when tz changes or
@@ -27,6 +33,11 @@ logger = logging.getLogger(__name__)
 _PERSISTED: dict[int, str] = {}
 _PERSIST_MAX = 2000
 
+# The middleware activates the visitor zone; DRF would then render API
+# datetimes in it under a literal "Z". Pin API output to UTC, as soon as
+# the middleware exists (AppConfig.ready is not wired for django_cfg).
+patch_drf_datetime_utc()
+
 
 class TimezoneMiddleware:
     def __init__(self, get_response):

django_cfg-2.3.332/src/django_cfg/startup/drf_datetime_utc.py

@@ -0,0 +1,46 @@
+"""
+django_cfg.startup.drf_datetime_utc — render DRF datetimes in UTC.
+
+django-cfg sets ``REST_FRAMEWORK["DATETIME_FORMAT"] = "%Y-%m-%dT%H:%M:%SZ"``
+(literal ``Z``). DRF's ``DateTimeField.to_representation`` converts an aware
+value to the *active* timezone before formatting, and ``TimezoneMiddleware``
+activates the visitor's zone from ``X-Timezone``. Result: local wall-clock
+time labelled ``Z`` (a +08:00 visitor got every datetime 8 hours late).
+
+Fix: render under ``timezone.override(UTC)``. Only the output path is wrapped
+(``to_representation``). Input parsing (``enforce_timezone`` from
+``to_internal_value``) still uses the active zone, so naive input keeps being
+read as visitor-local. Fields with an explicit ``default_timezone=`` argument
+keep it. Django admin, templates and non-API code are not touched.
+
+Patching the base class makes this global for plain ``serializers.DateTimeField``
+as well as ModelSerializer fields and subclasses, with no per-project changes.
+"""
+
+from __future__ import annotations
+
+import datetime
+
+_MARKER = "_django_cfg_utc_output"
+
+
+def patch_drf_datetime_utc() -> None:
+    """Idempotently wrap DateTimeField.to_representation. Called from AppConfig.ready."""
+    try:
+        from django.utils import timezone
+        from rest_framework.fields import DateTimeField
+    except Exception:
+        return
+
+    original = DateTimeField.to_representation
+    if getattr(original, _MARKER, False):
+        return
+
+    def to_representation(self, value):
+        with timezone.override(datetime.timezone.utc):
+            return original(self, value)
+
+    setattr(to_representation, _MARKER, True)
+    to_representation.__wrapped__ = original
+    to_representation.__doc__ = original.__doc__
+    DateTimeField.to_representation = to_representation