[Haskell-cafe] Logging

[MigMit]

Even if your app only works on your laptop, you might have a problem trying to dig through the logs that may or may not be on the day you were travelling (between time zones). Plus, again, DST. At least UTC have a benefit of not running backwards (most of the time).

Interestingly, I haven't got Tom's message either. I haven't checked the archives though, just assuming he sent his message to Joachim only, who resent it to the mailing list. But if it is in the archives, then it is somewhat strange.

> On 21 Nov 2021, at 23:55, Hilco Wijbenga <hilco.wijbenga at gmail.com> wrote:
> 
> On Sun, Nov 21, 2021 at 2:35 PM MigMit <migmit at gmail.com> wrote:
>> 
>> No, non-UTC logs are a nightmare when you have developers living in different time zones. Or even in one that is different from the one where the logs come from. Not only does it still have the same overhead, but it also adds DST troubles to the mix (yes, DST does not start at the same time everywhere) and is generally MORE confusing than just having everything in UTC.
>> 
>> Also, editors might be fast... but only if you don't have too much logs. I did work on one project where daily logs took tens of gigabytes in gzip. Editors were out of question, trying to load this in Emacs would just hang it. Things like zgrep were pretty much the only thing that could work. Another project simply used Datadog, and was way easier to work with, despite it being a web interface.
>> 
>> There could be some specific cases where logging in a local time zone is a good idea, but I don't think that happens often enough.
>> 
>>> On 21 Nov 2021, at 22:47, Joachim Durchholz <jo at durchholz.org> wrote:
>>> 
>>> Am 21.11.21 um 19:18 schrieb Tom Ellis:
>>>> It sounds really unwise to log timestamps in anything in other than
>>>> UTC.  If you want to see the logged times in your local timezone then
>>>> why not apply that conversion when you read the log?
>>> 
>>> UTC is wise only if you really have to deal with data originating from multiple timezones.
>>> Otherwise, it's just an additional interpretation step that makes it harder to read the raw logs - which not a very rare use case actually, editors are still the fastest way to find specific log records after all (mostly because you don't have to learn the web interface du jour just to search for something).
>>> 
>>> E.g. the application I'm working with logs to text files, and it always runs in the same time zone.
>>> UTC is just an extra hoop to jump through, with no added benefit.
>>> (Some users do live in a separate time zone, but we rarely need to correlate user-side and server-side logs, we go by session ids anyway.)
> 
> Strangely, while I can see Tom's message in the archives, _I_ never
> received it. Anyway, it seems I did not miss anything else.
> 
> Indeed, using UTC has its uses (especially when storing and/or
> comparing timestamps) but when viewing you definitely want to see your
> own TZ.
> 
> Clearly, the assumption seems to be that I'm working on some enormous
> application supported by several teams of developers in multiple time
> zones that generates massive log files. While it is nice to know that
> my reputation is such that it is automatically assumed that I'm
> creating the next Google ... in reality, it's just me and I'm working
> on a CLI app where I want to output some log messages. ;-) So I want
> to see my local time in the log messages.
> 
> Further research indicates that "logging" simply doesn't support my
> use case so I will look into writing my own wrapper around
> "fast-logger".
> 
> P.S. What is the etiquette here: top or bottom posting? Include all
> participants or just the list?