Hacker News Reader

Comment by 8organicbits | Hacker News Reader

I'm curious what your logs look like for 1am local time on Nov 6, 2022? I believe you set your clock back on that day, so 1am-2am would have happened twice.

Maybe your logs mention the timezone / UTC offset? Otherwise it would seem possible to get confused.

View on HN

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.

  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.

Nonesense. You can still print the offset and even if you don't, you can always infer which hour you are in from context.

> 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.

Or around any year that the daylight saving rules change.

Like 2007 ( https://www.timeanddate.com/news/time/us-daylight-saving-ext... ) and possibly 2024 ( https://www.reuters.com/world/us/us-senate-approves-bill-tha... ).

We don’t watch logs for fun. If issues get reported in local time, using UTC logs simply shifts the burden on an issue reporter (who may be clueless in this regard) and/or an investigator who now has to convert dates back and forth in their communication and probably while viewing, because let’s be honest barely anyone will scurpulously convert all dates into UTC with an additional tool, when it’s easy enough to subtract time in your head.

We could use both dates in logs, but that would eat an unreasonable amount of columns and confuse naive greps. We could also use non-standard time formats, e.g. <localtime8601>[<dst switch warning>] <unixtime>, but standard log handling tools aren’t built for it.

Reply on news.ycombinator.com