5 ms·

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 lap

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.

8organicbits 4y ago
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.
deleted 4y ago
[deleted]

8organicbits 4y ago

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.

deleted 4y ago

[deleted]