Bug 62161 - no way to ensure error log contains timezone in timestamps
Summary: no way to ensure error log contains timezone in timestamps
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.6
Hardware: PC Linux
: P2 minor with 4 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2018-03-06 21:06 UTC by James Ralston
Modified: 2023-07-17 21:22 UTC (History)
0 users



Attachments
ErrorLogFormat to accept "%{z}t" and "%{<strftime-format>}t" (3.37 KB, patch)
2023-01-27 10:19 UTC, Yann Ylavic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description James Ralston 2018-03-06 21:06:25 UTC
[I'm filing against 2.4.6, because this is the version of httpd included in Red Hat Enterprise Linux 7, where I've performed testing. But based on the documentation, I suspect this bug applies to all point releases in the 2.4 series, and additionally to 2.5-HEAD.]

We use the Splunk platform to analyze logs (including Apache httpd logs) that are combined across multiple hosts distributed across different time zones.

For this reason, it is critical to us that all timestamps in all logs contain timezone information.

For LogFormat, the %t format string includes the timezone offset from GMT. Additionally, a strftime(3) format string can be used with %{format}t. So for normal httpd logs, we have timezone offset information in the timestamps.

But, inexplicably, for ErrorLogFormat, the %t format string produces completely different output than LogFormat's %t format string, and that output doesn't include the timezone or timezone offset.

Furthermore, there is no %{format}t formatting string for ErrorLogFormat (as there is for LogFormat), and none of the other available ErrorLogFormat time formatting strings (%{u}t, %{cu}t) include the timezone or timezone offset.

This effectively means it is impossible to have httpd error logs that contain either timezone or timezone offset information in their timestamps.

This is a deficiency with ErrorLogFormat that should be corrected—ideally, by making ErrorLogFormat use the same time-related formatting strings as LogFormat, and by making them produce the same output.
Comment 1 Ondrej Brejla 2020-07-28 07:08:04 UTC
Hi all,

this issue is very annoying for everyone, it would be really nice to have it fixed :)

Thanks a lot!
Comment 2 Christian Lange 2022-08-04 06:51:11 UTC
Find it annoying two. Maybe it's possible to have the same configuration abilities for ErrorLogFormat and LogFormat?
Comment 3 nicolas 2023-01-26 14:31:35 UTC
This is really a must-have!

Having the same capabilities as LogFormat for the timezone part will be a great solution.
Comment 4 Yann Ylavic 2023-01-27 10:19:40 UTC
Created attachment 38485 [details]
ErrorLogFormat to accept "%{z}t" and "%{<strftime-format>}t"

ErrorLogFormat is about every log in any httpd context (loading, request, connection...), while LogFormat is always handled in the context of (the end of) a request where all informations regarding the request are known/populated.
That and for historical reasons too (probably) they don't share much code/formats.
For plain "%t" we can't change the output now, this would break for someone somewhere.

This patch adds strftime() format by looking up for a '%' in the format, to avoid (or minimize the chance of) breaking existing configurations like "%{abcdu}t" where everything but 'u' or 'c' was ignored.
It also adds the special "%{z}t" format (or still combined with the existing 'c' and 'u' ones like in "%{uz}t" or "%{cuz}t").
The default time format gets treated as a fast-path too (no ErrorLogFormat being handled as "%{u}t" internally).

Can you try it?
Comment 5 Yann Ylavic 2023-03-14 11:12:45 UTC
Checked in trunk (r1908380).
Comment 6 Graham Leggett 2023-07-17 21:22:15 UTC
Backported to v2.4.58.