Bryan J Smith wrote:
> Unfortunately, there's no real, unified standard for replacing user
> environment TZ. It's up to individual applications to support
> Zoneinfo correctly. Just because TZ is set with ":pathstring" doesn't
> mean the program will use it correctly, as GNU LibC, SunOS LibC,
> etc... intends.
Fortunately time formatting is enough of a hassle to do on one's own
that (on Linux, anyway) most people – including people who implement
library support for programming languages – will simply punt it to libc
(and hence zoneinfo). 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).
> In general, _avoid_ setting TZ (and _never_ set it system-wide), and
> use programs that use Zoneinfo directly with an user-specific setting,
> such as an attribute entry in a directory or some other attribute past
> from their remote system. Easier said than done, but there are
> solutions. ;)
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.
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.
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.
Anselm
--
Anselm Lingnau ... Linup Front GmbH ... Linux-, Open-Source- & Netz-Schulungen
anselm.ling...@linupfront.de, +49(0)6151-9067-103, Fax -299, www.linupfront.de
Linup Front GmbH, Postfach 100121, 64201 Darmstadt, Germany
Sitz: Weiterstadt (AG Darmstadt, HRB7705), Geschäftsführer: Oliver Michel
_______________________________________________
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
