-----Original Message----- From: Marth64 <marth64@proxyid.net> Sent: Friday, February 7, 2025 5:47 AM To: Soft Works <softworkz@hotmail.com> Cc: FFmpeg development discussions and patches <ffmpeg- devel@ffmpeg.org>; Michael Niedermayer <michael@niedermayer.cc>; Soft Works <softworkz-at-hotmail.com@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v3 0/3] Add option to log timing
it would probably also be odd when there's a single white space in- between.
Yes, it would look worse on white background. OK as is, then.
Fine. If someone has a specific wish or idea, feel free to comment.
Why wouldn't it be machine-parsable without those letters?
It is more about having timezone, etc. I actually think it is better for readability as is, but was checking if preservation for machine parsing* (phrasing what I meant better) was a goal, then it should be compliant. But I don't see much value in that.
We actually parse this output in some analysis tool, but only the time.
The example I was thinking of was if I wanted to look at the logs 2 years later, it would have time zone in case of DST or whatever. But it's a total obscure stretch case IMO. I'm not advocating for it, just sharing what I meant with my logic. (And if someone really needs it later they can make a +rfc3339 switch or whatever)
I don’t find that case "obscure" at all. In fact, the time zone can get really important when correlating information from multiple log files (e.g. ffmpeg + application). For this, we are printing the full date with time zone just once at the top of the logs and let ffmpeg print the time only. The date occupies a lot of horizontal screen estate which is inconvenient for manual review and largely redundant anyway. The only corner case would be a long-running process where ffmpeg doesn't print a single log line for a whole day - in that case, the time-only output would become ambiguous.. Thanks sw