@movq@www.uninformativ.de I fully support this! In the past I had to analyze and correlate events in log files and it was very hard without the timezones. One was in UTC and the other in UTC+X. Bonus if customer-reported times for the inquiry were in UTC+Y. Of course I always forgot until next time which log used which timezone. So I had to figure it out again and again. What a giant waste of time. :-(
However, that’s nothing compared to my current project. Here, I must deal with logs where the timezone is somehow part of the logs (I think), but the log viewer can be configured to display timestamps in a certain other timezone. Also, timestamps are generated by the logging service when receiving the event, not when the application actually produces it. Don’t ask. Often, timestamps are just plain wrong and not useable. Luckily, the uptime counter is included as well, which seems to be accurate from what we’ve seen so far. It’s by far the most horrible logging system I’ve ever come across. It gets extra funny when bug reports contain references to the timestamps in any other than the default timezone of the viewer. Of course reporters do not tell you. It’s a world-wide project, so chances are that timezones are all over the place. Unbe-fucking-leavable.