The problem/use-case that the feature addresses
The redis logs include datetime / timestamps in local timezone like the one below:
26838:C 27 Oct 2024 02:30:00.000 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
the utc offset for the timezone is not included.
So for the log entry above is not possible to determine if it happened 2024-10-27 02:30:00 +0100 or "2024-10-27 02:30:00 +0200". Specially since on 2024-10-27 03:00:00 +02:00 is when the daylight saving from CEST to CET happen, so on 2024-10-27 03:00:00 +0200 changes to 2024-10-27 02:00:00 +0100.
Description of the feature
I want a new configuration parameter that enables the printing of the timezone, so when the configuration parameter is set the log format will change from
26838:C 27 Oct 2024 02:30:00.000 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
to
26838:C 27 Oct 2024 02:30:00.000+0200 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
note the +0200
Alternatives you've considered
Forcing the timezone to be UTC by setting TZ="UTC", then the timestamp can be consistently parsed since the time printed does not shift due to daylight savings.
For example
date
Wed Jan 10 15:35:04 CET 2024
TZ="UTC" redis-server
27354:C 10 Jan 2024 14:35:04.766 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Additional information
Any additional information that is relevant to the feature request.
Comment From: madolson
@ecerulm If you were able to define an arbitrary stfrtime(), would that resolve your issue? I'm a little worried about changing it by default.
Comment From: ecerulm
I didn’t say to change the default
I want a new configuration parameter that enables the printing of the timezone,
An arbitrary strftime would be fine. But I think most people would be ok with a boolean option to print timestamps as ISO 8601 with utc offset like 2023-12-08T15:03:26.246+00:00 . That option can be off by default.
If the option to use arbitrary strftime is available I would use it but if just fixed iso 8601 is easier to implement I can settle for that
Comment From: madolson
My concern is just that there are multiple "valid" ISO 8601 timestamps, so it seems beneficial to be flexible moving forward. We happen to be working on a similar logging improvement, so I'll make sure we incorporate the ask from you into that change.
Comment From: ecerulm
I commented on that logging improvement PR #12934 that @madolson mentioned. But in summary the issues with strftime() are in my opinion:
* strftime format specification differences between operating systems
* strftime usually does not allow fractional seconds/ milliseconds / microseconds
Comment From: azuredream
Please review the sample output and let me know if that meets your requirement. https://github.com/redis/redis/pull/12934#issuecomment-1890072144