You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently logcli's default output mode has second resolution, which (as of recently) lags behind Grafana's explore view, which now shows milliseconds. I understand we get higher resolution timestamps with jsonl output, but the default output is the most convenient for common use cases.
The simplest solution is to change this line to use time.RFC3339Nano instead of time.RFC3339.
I can submit a PR for this.
The only question I have is whether this should be the default behavior, or whether subsecond resolution should be tucked behind a disabled-by-default flag. This change could break naive parsers of logcli output. IMO it should be default, with the old behavior restorable through a flag (such as --timestamps=seconds), but it could be the other way around, where a flag is required to enable more granular timestamps (such as --timestamps=nanos).
The text was updated successfully, but these errors were encountered:
Currently logcli's default output mode has second resolution, which (as of recently) lags behind Grafana's explore view, which now shows milliseconds. I understand we get higher resolution timestamps with
jsonl
output, but the default output is the most convenient for common use cases.The simplest solution is to change this line to use
time.RFC3339Nano
instead oftime.RFC3339
.I can submit a PR for this.
The only question I have is whether this should be the default behavior, or whether subsecond resolution should be tucked behind a disabled-by-default flag. This change could break naive parsers of logcli output. IMO it should be default, with the old behavior restorable through a flag (such as
--timestamps=seconds
), but it could be the other way around, where a flag is required to enable more granular timestamps (such as--timestamps=nanos
).The text was updated successfully, but these errors were encountered: