Unless someone convinces me otherwise (unlikely), I'll probably proceed fairly soon, to reconfigure the BALUG VM (Virtual Machine) - (host balug-sf-lug-v2.balug.org) and likewise "vicki" (hostname vicki - and the sometimes / semi-regular physical host of the BALUG VM) to default to using UTC. To minimize surprises/disruptions - in addition to this notice, I'll probably make that change upon a (re)boot of those hosts (e.g. on reboot, go to single user mode, reconfigure, then reboot per normal to multi-user).
Rationale: o security, etc. - many won't even consider looking at logs if they're not in UTC o no matter who uses it from where on the planet, one zone all can (well approximately) reasonably agree upon o no need/reason to change it in the (unlikely) even it moves to another physical location, or timezone at existing physical location changes o "principle of least surprise" - if it was a whole bunch 'o local folks doing admin, etc. on the box, and especially more "jr." folks, local would be of least surprise. But alas, yours truly does >>~=99.7 % of the systems administration, etc. on those hosts, so that being the case, and having been the case quite a while, and seeming improbable to change ... for me, that "principle of least surprise", and other reasons/advantages ... UTC o Users can always use TZ setting to whatever they wish that's available, we're only talking about the system default timezone, e.g.: $ TZ=America/Los_Angeles; export TZ
So ... did this a while ago, for "vicki" and the balug VM, changed the system default timezone 2019-05-26T23:23:22+0000 Michael Paoli reconfigured default system timezone to Etc/UTC ... and rather close in time to that, likewise on the vicki host.
And, more recently, updated some cron[tab] jobs, most notably I pushed most all the daily/weekly/monthly ones forward 8 hours. Why? To better correlate to / coordinate with local times, e.g. monthly email reminders/stats - to continue 1st of month, rather than local last of month. Also, sf-lug list backups, better correlate to grabbing those relatively freshly after their available, as opposed to - 7 or - 8 + 24 = about 16 or 17 hours after they become available, likewise keep those data transfers generally towards wee/early hours of the AM local time (at/towards minimum, or at least lower traffic periods).
From: "Michael Paoli" Michael.Paoli@cal.berkeley.edu Subject: BALUG VM (& "vicki" - sometimes physical host of BALUG): default timezone --> UTC (? Date: Sun, 26 May 2019 11:09:34 -0700
Unless someone convinces me otherwise (unlikely), I'll probably proceed fairly soon, to reconfigure the BALUG VM (Virtual Machine) - (host balug-sf-lug-v2.balug.org) and likewise "vicki" (hostname vicki - and the sometimes / semi-regular physical host of the BALUG VM) to default to using UTC. To minimize surprises/disruptions - in addition to this notice, I'll probably make that change upon a (re)boot of those hosts (e.g. on reboot, go to single user mode, reconfigure, then reboot per normal to multi-user).
Rationale: o security, etc. - many won't even consider looking at logs if they're not in UTC o no matter who uses it from where on the planet, one zone all can (well approximately) reasonably agree upon o no need/reason to change it in the (unlikely) even it moves to another physical location, or timezone at existing physical location changes o "principle of least surprise" - if it was a whole bunch 'o local folks doing admin, etc. on the box, and especially more "jr." folks, local would be of least surprise. But alas, yours truly does >>~=99.7 % of the systems administration, etc. on those hosts, so that being the case, and having been the case quite a while, and seeming improbable to change ... for me, that "principle of least surprise", and other reasons/advantages ... UTC o Users can always use TZ setting to whatever they wish that's available, we're only talking about the system default timezone, e.g.: $ TZ=America/Los_Angeles; export TZ