💾 Archived View for thrig.me › blog › 2023 › 11 › 06 › going-UTC.gmi captured on 2024-07-09 at 01:13:10. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-14)

-=-=-=-=-=-=-

Going UTC

Switching to UTC is not without problems. Local solar time with noon when the sun is more or less overhead has various advantages. Maybe less so when the local timezone is "too wide" and you're on an edge? Sunclocks are not the most useful of things in the Pacific Northwest. There is (or was) one on the side of a building by the Burke-Gilman trail, and it would most often be unusable (clouds, or the winter sun-b-gone thing) or off by an hour because of Daylight Saving Time (DST).

Some may need to interact with people who do use a local timezone. In particular one may set UTC at the system level, but then may need to generate events in a local timezone. cron(8) may not support scheduling events in multiple timezones, so you may need something fancier, or to regenerate the cron jobs (for UTC) following each DST wobble: more complexity, higher risk of bugs. Or on certain systems the timezone could be set to a local one, but then not all the systems are the same, which can cause bugs.

A redundant database pair was once found running with different timezones set. It was deemed too risky to correct one or the other. This was at a company that had started out in US/Pacific but then had gone global, so there were US/Pacific timezone servers (and, randomly, sometimes not) all over the world.

Another risk is when an admin sets their timezone differently from that of the system. Their user timezone may bleed over to the system level and a daemon may end up running with the wrong timezone. This should be tested for and guarded against. And documented, but folks tend not to read that. Sanitizing the environment is often a good thing: the web guy once caused mailman to crash with a weird message because of a weird environment variable carried over from a macbook.

Large browsers may leak the timezone (because, modern web) so you may want to set a specific timezone for software like that. UTC is not a terrible choice (especially with VPNs) though if you switch your user account to UTC you may want to keep the browser on the same old local timezone?

There's even more complexity if you get into leap seconds (or maybe minutes?) and UTC vs. TAI, but that's a different rabbit hole. Or you may encounter homeless wondering what day of the week it is.

/blog/2022/12/18/overclocked.gmi