Open zoutao0909 opened 1 month ago
The same problem. @zoutao0909 did you find how to resolve the problem?
The same problem. @zoutao0909 did you find how to resolve the problem?
There is no better way. In order to adapt to this situation, my current processing is: because the written time data is only converted in format, not in time zone, so when I specify the time during the query, I also convert the format of the incoming time without converting the time zone, so that the data found can meet my expectations. At the same time, the format conversion is also required when the data is displayed, without converting the time zone.
However, this makes it impossible to use the tail query supported in the new version, because tail seems unable to query data in the future
Is your question request related to a specific component?
VictoriaLogs
Describe the question in detail
Here, output to VictoriaLogs specifies json_date_format iso8601. When my time is ‘2024-07-29 14:57:14.415002’, the default time zone is +08:00, and the data finally written to VictoriaLogs is _time=2024-07-29T14:57:14.415002Z. The final time is 8 hours more than the actual time.
json_date_format java_sql_timestamp (for example: 2018-05-30 09:39:52.000681)
, but when I configure it this way, VictoriaLogs has a parsing error:Expected result: VictoriaLogs can support the time data parsing of
json_date_format java_sql_timestamp (for example: 2018-05-30 09:39:52.000681)
. When there is no time zone information in the time data, according to VictoriaLogs The current time zone of the service is converted to UTC time, instead of the default conversion to UTC time as it is now, but no time zone conversion is performed, resulting in inconsistency between the recorded time and the actual time when the log is generated.Troubleshooting docs