3 ms·

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

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.

throw0101b 4y ago
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.
inferiorhuman 4y ago
Or around any year that the daylight saving rules change.
- nayuki 4y ago
  Like 2007 ( https://www.timeanddate.com/news/time/us-daylight-saving-extended.html https://www.timeanddate.com/news/time/us-daylight-saving-ext... ) and possibly 2024 ( https://www.reuters.com/world/us/us-senate-approves-bill-that-would-make-daylight-savings-time-permanent-2023-2022-03-15/ https://www.reuters.com/world/us/us-senate-approves-bill-tha... ).
- wruza 4y ago
  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.

throw0101b 4y ago

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.

inferiorhuman 4y ago

Or around any year that the daylight saving rules change.

nayuki 4y ago
Like 2007 ( https://www.timeanddate.com/news/time/us-daylight-saving-extended.html https://www.timeanddate.com/news/time/us-daylight-saving-ext... ) and possibly 2024 ( https://www.reuters.com/world/us/us-senate-approves-bill-that-would-make-daylight-savings-time-permanent-2023-2022-03-15/ https://www.reuters.com/world/us/us-senate-approves-bill-tha... ).
wruza 4y ago
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.