Open crisvo2024 opened 2 weeks ago
This is because we use micro second precision when formatting ISO8601 format here: https://github.com/fluent/fluent-bit/blob/c69a6dfe9bd912892eb22dfddaa9101434e3ef8e/src/flb_pack.c#L1019-L1020
Thank you for your response. I have locally modified the .%06
specifier to .%09,
(in both cases where the format is either FLB_PACK_JSON_DATE_ISO8601
or FLB_PACK_JSON_DATE_JAVA_SQL_TIMESTAMP)
and altered the function msgpack_pack_formatted_datetime
replacing (uint64_t) tms->tm.tv_nsec / 1000
for tms->tm.tv_nsec
. These changes compiled successfully and seem to work perfectly.
However, I raised this issue because in the commit where this logic was introduced, it is explicitly specified to use microseconds instead of nanoseconds.
I am concerned about potential side effects that I might not have identified. Is there any rationality behind this decision? should I submit this change as a Pull Request?
Submitting as a Pull Request is awesome. But just changing the behavior is not good. This could be handled with the newly introduced format which should be called as iso8601_nanosec and its associated FLB_PACK_JSON_DATE_ISO8601_NANO or something like that.
Bug Report
Describe the bug While Using Fluent-bit with the HTTP output. We discovered that the Timestamp precision is set to microseconds whenever the output is set to use format = json/json_lines format with json_date_format = iso8601/java_sql_timestamp
To Reproduce
[0] dummy.0: [[1724678026.592204311, {}], {"message"=>"dummy"}] [0] dummy.0: [[1724678027.592222041, {}], {"message"=>"dummy"}] [0] dummy.0: [[1724678028.592239349, {}], {"message"=>"dummy"}]
fluent-bit -i http -p port=8888 -o stdout
[0] http.0: [[1724678027.595000026, {}], {"date"=>"2024-08-26T13:13:46.592204Z", "message"=>"dummy"}] [0] http.0: [[1724678028.593061832, {}], {"date"=>"2024-08-26T13:13:47.592222Z", "message"=>"dummy"}] [1] http.0: [[1724678028.999138761, {}], {"date"=>"2024-08-26T13:13:48.592239Z", "message"=>"dummy"}]