Winevtlog plugin does not include DST in UTC offset#8386
Winevtlog plugin does not include DST in UTC offset#8386laurensknoll wants to merge 1 commit intofluent:masterfrom
Conversation
Signed-off-by: Laurens Knoll <3205006+laurensknoll@users.noreply.github.com>
laurensknoll
requested review from
edsiper,
fujimotos,
koleini and
leonardo-albertovich
as code owners
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
Hi @edsiper , @leonardo-albertovich , @fujimotos and @koleini , Could you tell me what is needed to get the PR under review? |
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
Hi @edsiper , @leonardo-albertovich , @fujimotos and @koleini , Could you tell me what is needed to get the PR under review? The item has turned stale by now. |
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
There was a problem hiding this comment.
It's not recommended way to convert DST. This is because this hand-written conversion is only active for activated system for DST.
If we could use well maintained functions for this type of conversions, we need to use them.
I sent another PR:
#10628
|
Superseded by #10628. |
|
Thanks for fixing the issue @cosmo0920 👍 Great to see the use of the DynamicTimeZoneInformation function. Please note that the non-dynamic/custom method is still used by the in_windows_exporter_metrics-plugin. Could you take a look at that as well? fluent-bit/plugins/in_windows_exporter_metrics/we_os.c Lines 226 to 246 in 2b9741c |
|
Ah, thanks for the catch of remaining usages of static TimeZone handling functions. I'll handle them! 👍 |
2 participants
Winevtlog does not include DST in UTC offset
This change ensures that the local times emitted by the
winevtloginput plugin include daylight savings time. Daylight savings time is respected as in thewindows-exporter-metricsinput plugin ref.The issue arises when the Windows event log entry time (UTC) is converted into a local time, and becomes apparent after forwarding the event to Stackdriver (Google Cloud Logging):
winevtloginput plugin outputs the value as local timeThe time is displayed in local time (Sydney time zone, UTC +10:00), but does not include DST. The expected offset is +1100.
{ "TimeCreated"=>"2024-01-16 02:48:24 +1000" }stackdriverThe event time is outputted as
timestampref in UTC.{ "jsonPayload": { "TimeCreated": "2024-01-16 02:48:24 +1000" }, "timestamp": "2024-01-15T15:48:24Z", "receiveTimestamp": "2024-01-15T14:48:26.45698121Z", }The issue becomes apparent when Google Cloud Logging, on receive, adds a
receiveTimestamp. This timestamp indicates that the event is from the future, because the UTC offset was not correct (+1000 instead of +1100 due to daylight savings time).Enter
[N/A]in the box, if an item is not applicable to your change.Testing
Before we can approve your change; please submit the following in a comment:
This change does not add any new features to the Fluent Bit binary.
See below.
Valgrind does not run on Windows. Any recommendations on running Valgrind otherwise?
If this is a change to packaging of containers or native binaries then please confirm it works for all targets.
ok-package-testlabel to test for all targets (requires maintainer to do).This change does not touch the packaging.
Documentation
The documentation does not mention UTC to local time conversion.
Backporting
Unsure. Google Cloud Logging accepts entries up to 24 hours in the future. Impact on other outputs is not clear.
Debug output
Debug output from non-fixed build:
Debug output from fixed build:
Fluent Bit is licensed under Apache 2.0, by submitting this pull request I understand that this code will be released under the terms of that license.