https://bz.apache.org/bugzilla/show_bug.cgi?id=57339
--- Comment #16 from Michael Osipov <micha...@apache.org> ---
(In reply to Yann Ylavic from comment #13)
> (In reply to Michael Osipov from comment #12)
> > Yann, there are actually several issues of you read my comments above. I
> > hesitated to open more issues since there was no traction here.
>
> So r1921259 changed the description of %{c}t to "The current time in ISO
> 8601 extended format (compact)", does it work for you?
Yes, this does.
> As for the "T' separator is missing", wikipedia says "Earlier versions
> omitted the T (representing time) in both formats", I think httpd is using
> such old version, and the docs talk about ISO 8601 for the time format
> alone, not the whole date string.
That statement is not correct. I have just opened ISO 8601:2000 through my
employer's portal and it says:
5.4.1:
> The character [T] shall be used as time designator to indicate the start of
> the representation of time of the day in date
> and time expressions. The hyphen [-] and the colon [:] shall be used, in
> accordance with 4.5, as separators within the
> date and time of the day expressions respectively, when required.
> NOTE By mutual agreement of the partners in information interchange, the
> character [T] may be omitted in applications
> where there is no risk of confusing a combined date and time of the day
> representation with others defined in this International
> Standard.
So, it has to be with "T" since there cannot be a mutual agreement with an
anonymous party. The same problem occured in git-log and that is why they
implemented 'iso8601-strict' for that. Similar bug in LogBack:
https://jira.qos.ch/browse/LOGBACK-1303
> Anyway I think it's too late to change the existing %{cuz}t format, we could
I agree that is it too late and it is actually broken another way:
> 2024-10-11 19:17:48.482240 +0200
The offset does not comply with ISO 8601:2000 since the space is not allowed
and all components need to be in the same format: extended or basic. Not mixed
(strftime's "%z" is not usable here). Ideally, you'd change the docs for
"cu"/"cuz" that they do not fully comply.
> add another another letter there to mean use ISO8601 / RFC3339 format for
> the whole date but at this point it's probably clearer to have:
> - %{rfc3339}t => yyyy-mm-ddThh:mm:ss+hh:mm
> - %{rfc3339_usec}t => yyyy-mm-ddThh:mm:ss.uuuuuu+hh:mm
> - %{rfc3339_utc}t => yyyy-mm-ddThh:mm:ssZ
> - %{rfc3339_utc_usec}t => yyyy-mm-ddThh:mm:ss.uuuuuuZ
> usable for both ErrorLogFormat and mod_log_config's CustomLog/LogFormat.
I'd agree with those, but I wouldn't even go through the indirection of RFC
3339, but straight to ISO 8601:
%{iso8601}t
%{iso8601_usec}t
%{iso8601_utc}t
%{iso860_usec_utc}t (intentionally) inverted because the TZ offset applies ot
the actual time, not the microseconds to UTC.
Also note that in the offsetted versions in the case the machine is in Etc/UTC
the printed offset must be "Z", not "+00:00". See also my report with Git:
https://lore.kernel.org/git/410d458c-ae5b-40cc-9c8e-97b016c74...@siemens.com/
Thank your for your time.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
