On Wed, Apr 1, 2015 at 1:57 PM, Anselm Lingnau <[email protected]> wrote: > So from the POV of Linux administration, anything > that gets GNU libc to produce the appropriate local time is probably > good enough for government work (and that would include setting TZ in > suitably desperate user-specific cases where relying on /etc/localtime > doesn't cut the mustard).
Assuming the TZ Zoneinfo string is set correctly by the user, for the release. It sounds easy. But in reality, it's not. I've written ~/.profile files for users in different Zones. > That would also work, but has the disadvantage that having to figure out > exactly how to get any of a potentially large number of applications to > obey a non-default time zone setting is certainly more of a hassle than > doing the Right Thing with the TZ variable in the first place. Or just bypass the TZ variable altogether and rely on another "Conf" solution. ;) > The main problem with TZ is that it allows a user to either set an > explicit rule for a time zone (including rules for daylight savings time > start and stop dates) or else set up something system-specific which, > depending on the underlying operating system and/or language environment > may or may not refer to the Zoneinfo database (but on systems that have > Zoneinfo usually does). We agree that an explicit time zone definition > in TZ is usually a bad idea, so what we want is a sure-fire way of > specifying a user-specific time zone according to Zoneinfo. On > mainstream Linux, the name of a file below /usr/share/zoneinfo (possibly > with a colon in front in case you want to be POSIXly correct) should do > the trick, and on other systems one will have to see what works because > we cannot with 100% certainty assume that the Zoneinfo database will > even be available. There are so many variables, but slow, over time, more and more platforms and applications are supporting TZ=":zonepath" correctly. > Hence, I'll go on teaching the participants in my Linux classes to: > 1. Ensure that the default time zone for the system is set up in > /etc/localtime (either manually, using the system's installation > tool, or timedatectl if available). > 2. Use the TZ variable to specify a time zone from the Zoneinfo database > for users or instances of programs where the default time zone is > not appropriate. > 3. If that doesn't seem to work, check whether the offending > application has some non-standard way of specifying a time zone, > and use that instead. That logic is a sound base. Sorry I went deep on this. I had an entire engineering team to educate on a decade ago, and it radically changed an already released product and infrastructure world-wide. I made sure I got it right the first time. ;) -- bjs _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
