5 ms·

> servers should always be UTC All of the servers I run are located in Toronto, Canada: why do I care about UTC? What would having all of them being UTC get me

> servers should always be UTC All of the servers I run are located in Toronto, Canada: why do I care about UTC? What would having all of them being UTC get me? A few jobs ago I took care of servers that were in: California, Ontario, Quebec, Switzerland, Singapore. UTC made sense there.

deleted 4y ago
[deleted]
tomrod 4y ago
Clarity as to your server time no matter what time zone nonsense a government devises.
- throw0101b 4y ago
  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
  - deleted 4y ago
    [deleted]
inferiorhuman 4y ago
Maybe you aren't on top of keeping your timezone database up to date, maybe you have to deal with dates spanning 2005, maybe Ontario will finally abolish DST. Using UTC simplifies time handling with very little downside.
- throw0101b 4y ago
  I lived through the changes of 2005 as a sysadmin: * https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Chan... From a Unix perspective (Solaris, Linux, IRIX), it was fine. And Ontario has provisionally passed getting rid DST changes (sadly in favour of going to year-round DST), and IMHO it will be fine again if it is ever finalized: * https://toronto.ctvnews.ca/ontario-passes-legislation-to-make-daylight-time-permanent-1.5205131 https://toronto.ctvnews.ca/ontario-passes-legislation-to-mak...
  - inferiorhuman 4y ago
    Sure. And we all survived Y2K. Point being that setting your servers to UTC is one less thing to worry about. I'd flip the argument on its head and posit that there's no compelling reason to use anything other than UTC. So long as you keep your TZ database up-to-date local time is likely to be not-so-problematic. Once you have that one server in a closet that didn't get updated, all bets are off.
    - throw0101b 4y ago
      > Point being that setting your servers to UTC is one less thing to worry about. It's only one less thing to worry about if you worry about it in the first place. I do not. > I'd flip the argument on its head and posit that there's no compelling reason to use anything other than UTC. There is a compelling, or at least useful, reason for me; from another reply I did: 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.
nine_k 4y ago
One upside is that there is no, and there cannot be any, daylight savings time jumps, or any other offset changes, now or in the future. Local time is governed by local authorities; UTC, much less so.
- cyberpunk 4y ago
  Why is that an upside? I mean, clocks go out of sync, every few (days? Weeks?) I assume the ntp client has adjusted actual local time on your server; not just the time zone your server translates it to when you run “date” we are talking about here… If it can handle that, it can handle a tz with dls time.
  - nine_k 4y ago
    Clocks going backwards for a whole hour is massively more trouble than clocks compensating a few seconds of discrepancy. Usually being a few seconds ahead is compensated by running the clock slower for some time. Showing the clock to compensate a whole hour breaks many kinds of assumptions. But jumping the clock actually back an hour breaks even more assumptions that look entirely sane. Better off without it.
lamontcg 4y ago
> why do I care about UTC? Eliminates all the software bugs due to non-monotonically increasing time. If you get bought by a company in the EU/UK or vice versa then it ultimately makes it easier to deal with time as you become part of a global company.

deleted 4y ago

[deleted]

tomrod 4y ago

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

throw0101b 4y ago
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
- deleted 4y ago
  [deleted]

inferiorhuman 4y ago

Maybe you aren't on top of keeping your timezone database up to date, maybe you have to deal with dates spanning 2005, maybe Ontario will finally abolish DST. Using UTC simplifies time handling with very little downside.

throw0101b 4y ago
I lived through the changes of 2005 as a sysadmin: * https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Change_to_daylight_saving_time https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005#Chan... From a Unix perspective (Solaris, Linux, IRIX), it was fine. And Ontario has provisionally passed getting rid DST changes (sadly in favour of going to year-round DST), and IMHO it will be fine again if it is ever finalized: * https://toronto.ctvnews.ca/ontario-passes-legislation-to-make-daylight-time-permanent-1.5205131 https://toronto.ctvnews.ca/ontario-passes-legislation-to-mak...
- inferiorhuman 4y ago
  Sure. And we all survived Y2K. Point being that setting your servers to UTC is one less thing to worry about. I'd flip the argument on its head and posit that there's no compelling reason to use anything other than UTC. So long as you keep your TZ database up-to-date local time is likely to be not-so-problematic. Once you have that one server in a closet that didn't get updated, all bets are off.
  - throw0101b 4y ago
    > Point being that setting your servers to UTC is one less thing to worry about. It's only one less thing to worry about if you worry about it in the first place. I do not. > I'd flip the argument on its head and posit that there's no compelling reason to use anything other than UTC. There is a compelling, or at least useful, reason for me; from another reply I did: 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.

nine_k 4y ago

One upside is that there is no, and there cannot be any, daylight savings time jumps, or any other offset changes, now or in the future. Local time is governed by local authorities; UTC, much less so.

cyberpunk 4y ago
Why is that an upside? I mean, clocks go out of sync, every few (days? Weeks?) I assume the ntp client has adjusted actual local time on your server; not just the time zone your server translates it to when you run “date” we are talking about here… If it can handle that, it can handle a tz with dls time.
- nine_k 4y ago
  Clocks going backwards for a whole hour is massively more trouble than clocks compensating a few seconds of discrepancy. Usually being a few seconds ahead is compensated by running the clock slower for some time. Showing the clock to compensate a whole hour breaks many kinds of assumptions. But jumping the clock actually back an hour breaks even more assumptions that look entirely sane. Better off without it.

lamontcg 4y ago

> why do I care about UTC? Eliminates all the software bugs due to non-monotonically increasing time. If you get bought by a company in the EU/UK or vice versa then it ultimately makes it easier to deal with time as you become part of a global company.