From: Matthias A. <mat...@gm...> - 2022-01-30 20:28:06
|
Am 30.01.22 um 04:52 schrieb grarpamp: > > Existance of 8601 allows apps to advertise they are > using a standard format, that the world has agreed > through ISO process, by default for any timestamps > that may be present in the apps logs. But since there > are no such shipped LC_TIME, and locale does not split > between GUI and log, the apps have to do the log, > letting user override via some app config. > "Locales" are meant for use in equivalent of > human interface / display / GUI, but are pain > in the ass trying to make them serve for log > since they require reversing tools to do anything > programmatic with, if they are even parseable > at all due to other log problems in the apps. It's as simple as "if your log is in a locale I do not understand, I am not supporting you". Review https://www.fetchmail.info/fetchmail-FAQ.html#G3 again and find it enforces LC_ALL=C to stomp over everything with the master switch and get me the ANSI-C locale. Available everywhere since 30+ years. And while the C standard %a %b %e %H:%M:%S %Y is neither ISO8601 nor logical, it is usable. I am the programmer you know... > People who never had to look at, digest, parse, > filter, sort, merge, store, extract, etc all sorts > of logs, unfortunately often may not yet appreciate > the wisdom of using 8601 for logs. 8601 serves > both the programming and reading purposes in logs. ...and there is something called "compatibility" on the other side of the scales. It will likely happen, but not before fetchmail 7. Please file a *short* reminder (don't write an epic) on the Gitlab project site, milestone 7.0, with just "consider switching date-and-time formats to ISO8601" and reference the mailing list archive for this thread, and possibly two or three bullet points with the key items, that's enough. |