Hacker News Reader

Comment by tomrod | Hacker News Reader

Clarity as to your server time no matter what time zone nonsense a government devises.

Using UTC when all of my servers are in one timezones actually decreases clarity, as I live in America/Toronto with my daily existence, and which is what my laptop and (mechanical) wristwatch† are set to. If I less(1) the logs I now have to do mental math as to "when" things happen because the hour number it says in the logs does not match my human reality.

If I look at something now (at Mar 25 21:09) the logs would say "Mar 26 01:09" which is not "now" in my mind.

† Though I've been toying with the idea of getting a GMT watch "for fun". However I'll probably go with a chronograph—more useful feature on a day-to-day basis. Not as many choices if I want to get both complications though.

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.

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