Thanks.  That's a great analysis and incredibly helpful!

I will investigate further and get back to you.

Thanks again!

Toby 

I think I found the reason why I get another behavior: Language settings control the decimal separator. I have a comma normally, but when switching to a dot and restarting Log view plus the numbers are converted to the correct dates.

I can also fix the current file by wrapping the timestamps like this "1748025592.9556797" which results also in a correct conversion.

It seems like LogViewPlus is using the local decimal separator setting when parsing numbers when it always should use a dot for JSON log files as JSON only supports dot as separator.

Hi TobZip,

Thanks for reaching out.

You can parse these log entries using the ElapsedDateTimeDecimal flag.  I am not sure why you are getting dates in the future. 

For example:

{
    "level": "%p",
    "ts": "%d{ElapsedDateTimeDecimal}",
    "logger": "%c",
    "msg": "%m"
}

This gives something like:



Hope that helps,

Toby

I have a log file file from caddy with json log entries like this:

{"level":"info","ts":1762473914.5372682,"logger":"http","msg":"enabling HTTP/3 listener","addr":":29250"}
{"level":"info","ts":1762473914.537774,"logger":"http.log","msg":"server running","name":"srv0","protocols":["h1","h2","h3"]}

When using a json parser the only elapsed date pattern that let me finish the wizard is %d{ElapsedDateTimeDecimal}, which is not correct anyway and produces timestamps some thousand years in the future.

When checking the time stamp here https://www.epochconverter.com/ it is convertible to human readable form.

Is there a way to parse this in LogViewPlus? Can this be added otherwise? Also it would be nice to update the documentation for elapsed time patterns with example values and limitations if it is not possible.

Thanks!