Document adding timezone offset to Apache error log timestamps.

Expand the timezone section of the application issues guide to explain
the ErrorLogFormat %t options (c/u/z) and give verified, ready-to-use
ErrorLogFormat examples that reproduce the default layout with a timezone
offset added, using %{uz}t or compact ISO 8601 %{cuz}t. Warn about the
leading-% strftime pitfall and note that the c/u/z options are formatted
by Apache itself and are portable across Linux, macOS and Windows whereas
strftime forms are not. Frame the whole as a partial mitigation that
follows from the TZ recommendation rather than a separate aside.

Author: GrahamDumpleton

docs/user-guides/application-issues.rst

@@ -344,14 +344,69 @@ matches the default for many applications, including Django when
 ``TIME_ZONE`` is left at its ``UTC`` default. If the application uses a
 different timezone, set ``TZ`` to that same timezone instead.
 
-Note that there is no Apache log format directive which will solve this by
-forcing UTC. Both ``ErrorLogFormat`` and ``CustomLog`` / ``LogFormat``
-format their ``%t`` timestamps from the process's local time, derived from
-``TZ``; even the compact ISO 8601 forms such as ``%{cu}t`` use local time,
-not UTC. The ``%{cuz}t`` form (Apache 2.4.58 and later) at least appends
-the numeric timezone offset, so lines stamped in different timezones can
-be told apart rather than silently misread, but it does not make them
-consistent.
+Where you are not able to change how Apache is started, a log format
+directive offers a partial mitigation, though not a cure. It is worth
+being clear about its limits, because reaching for the log configuration
+is the natural first instinct. No ``ErrorLogFormat`` or ``CustomLog`` /
+``LogFormat`` option can force these timestamps to a fixed zone such as
+UTC; ``%t`` is always formatted from the emitting process's local time,
+derived from ``TZ``. What a log format *can* do is make the timezone of
+each line explicit, so that lines stamped by processes in different
+timezones can be told apart rather than silently misread.
+
+In an ``ErrorLogFormat`` the ``%t`` field accepts a small set of single
+letter options inside the braces:
+
+* ``%t`` produces the default ``ctime`` style, ``Fri Jun 05 08:42:44 2026``.
+* ``%{u}t`` is the same but with microseconds. This is what the Apache
+  default ``ErrorLogFormat`` uses.
+* the ``c`` option switches to the compact ISO 8601 form,
+  ``2026-06-05 08:42:36``.
+* the ``z`` option (Apache 2.4.58 and later) appends the numeric timezone
+  offset, ``+1000``.
+
+The options combine, so ``%{cu}t`` is compact ISO 8601 with microseconds
+but still no offset, and ``%{cuz}t`` is that with the offset added on the
+end.
+
+To keep the familiar default layout and simply add the timezone offset,
+take the Apache default ``ErrorLogFormat`` and change its ``%{u}t`` field
+to ``%{uz}t``::
+
+    ErrorLogFormat "[%{uz}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+
+A line then looks like the following, identical to the default apart from
+the trailing ``+1000``::
+
+    [Fri Jun 05 08:42:29.986168 2026 +1000] [mpm_event:notice] [pid 37192:tid 140704575428864] AH00489: ...
+
+If you prefer the compact ISO 8601 timestamp, use ``%{cuz}t`` instead::
+
+    ErrorLogFormat "[%{cuz}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M% ,\ referer\ %{Referer}i"
+
+    [2026-06-05 08:42:36.978307 +1000] [mpm_event:notice] [pid 37243:tid 140704575428864] AH00489: ...
+
+A word of caution about the syntax. The ``c``, ``u`` and ``z`` letters are
+options, not ``strftime`` conversions, and must appear directly inside the
+braces with no leading ``%``. If you write ``%{%cuz}t`` instead of
+``%{cuz}t``, the leading ``%`` switches the field into ``strftime`` mode,
+where ``%c`` expands to the C library's locale date and time and the
+remaining ``uz`` is copied through literally, producing nonsense such as
+``Fri Jun  5 08:42:25 2026uz``.
+
+This distinction also matters across platforms. The ``c``, ``u`` and ``z``
+options are formatted by Apache itself and behave identically on Linux,
+macOS and Windows. The ``strftime`` forms, such as ``%{%d/%b/%Y %T}t``,
+are passed to the platform C library's ``strftime(3)``, whose set of
+supported conversions varies; Windows in particular omits or alters
+several of them, with ``%z`` for example yielding a timezone name rather
+than a numeric offset. Preferring ``%{cuz}t`` over a hand written
+``strftime`` string therefore also gives consistent output everywhere.
+
+Adding the offset lets the two timezones be distinguished, but it does not
+make them consistent. The only way to have every process agree remains to
+start the Apache parent process with the same ``TZ`` the application uses,
+as described above.
 
 Be aware also that this only addresses divergence between processes. If a
 single daemon process hosts multiple sub interpreters that set different