5 ms·

I have no idea because (a) I didn't experience any problems that needed debugging at that moment so I've never looked, and (b) I wasn't awake looking at the log

I have no idea because (a) I didn't experience any problems that needed debugging at that moment so I've never looked, and (b) I wasn't awake looking at the logs for fun at the time. But I do sometimes have to look at the logs on some random Tuesday, mid-morning, when someone says they can't log into our SSH bastion hosts (but it worked yesterday), I can see there's failed password attempts at 09:59, 10:03, and 10:04 (versus 13:59, 14:03, and 14:04 (i.e., UTC+4), which I would then have to do mental math to bring back to local time), and so it turns out they entered their password wrong a few of times so fail2ban blocked their IP Wallclock time is a human construct created for human convenience. Having UTC when all my servers are in America/Toronto is not convenient for me.

inferiorhuman 4y ago
Having UTC when all my servers are in America/Toronto is not convenient for me. Until you have to debug something that straddles DST changes.
- filmor 4y ago
  Nonesense. You can still print the offset and even if you don't, you can always infer which hour you are in from context.
- throw0101b 4y ago
  > Until you have to debug something that straddles DST changes. I will perhaps consider doing it at that point, but in ~20 years of being a sysadmin I have never needed to, so… ¯\_(ツ)_/¯ Therefore I optimize for the common case: looking at logs when events do not straddle DST changes.