[buug] UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time)

[Michael Paoli]

UTC, or not to UTC (Unix/Linux/BSD/etc. system default "local" system time)

So ... one of the things I brought up at last BUUG meeting
(unfortunately looks like I won't make this week's meeting - have a
calendar conflict ... hopefully someone there can bring or fashion some
reasonable facsimile of a BUUG sign/placard) ... setting system default
"local" time to UTC - various pros and cons and considerations (and for
system that's typically not physically located in UTC/GMT0 - and may or
may not travel about and/or be relocated).

Teensy background - I've been setting up my new personal laptop (
Debian GNU/Linux 6.0.3 "Squeeze" - Official amd64;
old (over 8 years old) personal laptop started seriously failing
2011-11-27) ... and when it came to matter of setting default "local"
system timezone, I was thinking, why *not* UTC?  :-)  Decision's not
exactly cast in stone, but thus far I've set it up using UTC.

So, ... considerations, advantages, disadvantages, etc.

Pros:

o system log submissions/comparisons: a key advantage of UTC is system
   (and security) logs.  E.g., in many cases, other
   organizations/entities/person(s) won't even look at, review, consider,
   or accept log data, unless it's UTC.  This is, e.g., particularly the
   case often when reporting Internet security incidents.
o fairly logical timezone for system that does or may travel a fair bit
   (e.g. laptop)
o fairly logical timezone for organization(s)/entities, etc., that span
   multiple timezones
o relative immunity to relocations and timezone law changes (e.g.
   corporate headquarters or data center moved to a different timezone?
   Or changed one's country's timezone due to primary economic trading
   partners?)
o general reduction in ambiguity and confusion - e.g. timezone of
   PST8PDT / US/Pacific - log indicates Sun Nov  6 01:30 or 1:30 AM ...
   was that PDT or PST ? - as both occurred.
o cron/crond/crontab - avoid all that ambiguity about when stuff will
   run across time or timezone changes or transitions - e.g. to/from
   Daylight Saving Time / Summer Time, or if changing system timezones
   due to travelling/moving/moved system (e.g. laptop) or political/legal
   reasons (changes in law).

Cons(?):
Not a whole lot, but here are the ones I'm aware of:

o cron/crond/crontab - it has and runs in just one timezone at any given
   time, might be confusing - particularly for mere mortal regular users,
   if it's not running in the actual local timezone where system is (or
   at least primarily is) located.  (There are probably ways to partially
   mitigate that - but not fully - at least presently?)
o "user" confusion(?) - some/many users may be at least somewhat (more)
   confused if the default system timezone isn't the actual local time
   where the system is (or typically is) located.  There are, however,
   ways to (mostly) mitigate that.  E.g. /etc/skel files can be set up so
   that by default, regular user accounts are configured to use a more
   customary timezone, e.g.:
   ! [ -r "$HOME"/.TZ ] || ! [ -f "$HOME"/.TZ ] || . "$HOME"/.TZ
   and with suitable .TZ default file.  Also PAM or similar might be
   potentially quite useful to generally ensure "regular user" sessions
   have a suitably set timezone, at least initially by default, and
   pretty much regardless of at least most of the various means by which
   such a "user session" was initiated.
   Various communication(s) - particularly when account is first issued,
   and perhaps at least occasionally or more often thereafter (e.g. a
   reminder line in /etc/issue and/or equivalent(s)) - perhaps also with
   pointer(s) to relevant information/documentation
o with a UTC system default timezone, and (many/most) users using other
   timezone(s), examining/comparing/contrasting - especially directly
   user generated - logfile information and the like, may be a bit more
   confusing.  But do note however that generally users can always set
   their timezone anyway, so there's always at least some ambiguity or
   potential confusion there anyway.
o "localtime" - for many utilities, library calls, even some
   filename(s), etc. - if UTC is system default timezone (but system
   isn't physically in UTC timezone), then "localtime" is a bit
   misleading.  Maybe those ought instead to say systemdefaulttimezone or
   something like that ;-) ... but a wee bit late to change that :-/.

Anyway, those are most of my thoughts on the matter.  Thus far I'm
using and generally leaning towards UTC for default "local" system
timezone.  If the user base were broader, I'd probably also have some
/etc/skel adjustments - and some communication/notification bits in
place, and likely also some scripts/hooks in place on setting up
accounts - e.g.  for "regular user" accounts, would likely want them to
have a customary local timezone set up for them (at least by default),
but, e.g., various system utility accounts that may get created - would
probably want most of those to generally default to using the system
default "local" timezone.

Oh, and hardware clock - let's not even get into that :-> UTC is and
always has been the right way to do that.  :-)  (possibly
notwithstanding some occasional twisted desires to be compatible and
relatively co-existent with some drain bamaged excuses for an operating
system - or maybe even very broken hardware?)

So, ... curious, ... your thoughts?  :-)