All right, the TZ variable was poorly standardized across architectures and poorly implemented. However, I was not questioning it's mention in the LPI-102 objectives, I only focused on the officially deprecated tzconfig command. The question concerning TZ might be felt an uneasy one, but I think there is not much ground to grant it's removal from the objectives, if that's what you meant to say. There are many thing still poorly or partially implemented, yet good to know or necessary to deal with. In the case at hand, setting the TZ variable is the only way a user has to set a personalized timezone overriding system settings. It should work, it might not work depending on the particular distribution, release, GNU C library version, installed timezone db etc., but it's still the only way a user can choose a custom timezone setting, and I think people should be aware of it.
Secondly, the same document you quoted reports a very similar comment compared to Anselm's: «You might set |TZ| if you are using a computer over a network from a different time zone, and would like times reported to you in the time zone local to you, rather than what is local to the computer.» It also explains the rationale behind the reason one should not set this variable: it's just that the system's default should be adequate for most people. Alessandro Il 01/04/2015 15:23, Bryan J Smith ha scritto: > Just to take this one step further, even GNU LibC has continued to > wrestle with this. [1] > > QUOTE: > > "The third format looks like this: > :characters > > Each operating system interprets this format differently; > in the GNU C Library, characters is the name of a file which > describes the time zone.' > [1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html > > I kid you not when I spent a lot and I mean a _lot_ of time in the > '00s, with Linux distros (even putting AIX v. HP/UX v. Solaris, etc... > aside), where the colon v. non-colon v. any Zoneinfo path (both > absolute to /usr/share/zoneinfo or relative Continent/City path) > produced countless different results. > > Officially GNU, like Solaris, actually requires a leading colon (:), > to use Zoneinfo. Using the legacy abbreviations can absolutely result > in ambiguity, other than "UTC" (which never does). The good news is > most implementations these days assume colon (:) if they get a > "proper" Zoneinfo path (e.g., America/New_York and _not_ US/New_York > or, worse yet, US/Eastern). > > But it's these types of non-standard variations and decrepancies that > continue to plague not just all POSIX systems, but even Linux. This > was also why I continually understood why Drepper (who has taken a lot > of repeat flak over the years, the same'old same'old over decades on > why he wouldn't change something) was always hesitant to change GNU > LibC, because even the best intentions could result in major breakage. > > - bjs > > [1] http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html > > > On Wed, Apr 1, 2015 at 9:12 AM, Bryan J Smith <[email protected]> wrote: >> On Wed, Apr 1, 2015 at 4:48 AM, Anselm Lingnau >> <[email protected]> wrote: >>> Bryan J Smith wrote: >>>> Legacy kinda like the POSIX "TZ" environment is still there, even >>>> though it is strongly recommended to _never_ set it at all. >>> I don't buy this. How do you propose a user should set a different time >>> zone from the system time zone? >> Don't know. >> >> Unfortunately the iEEE/TheOpenGroup Austin et al. Working Groups >> always did a poor job of addressing this. This may have changed in >> the last couple of years, but even in the '00s, it was poorly >> implemented consistently across most POSIX platforms. >> >> E.g., setting a Zoneinfo path in the TZ environment for an user does >> not always work. >> >> In general, the only time one should set TZ is for UTC. Otherwise, >> leave it blank if at all possible. >> >> This is a long-standing application/POSIX issue. Because applications >> should offer a way, and TZ has such a poor history of inconsistency in >> implementation, even in the age of Zoneinfo. And nothing else has >> been done well. >> >>> E.g., because a user in Australia is >>> ssh'ing into a machine that is in the UK, with the system time zone set >>> to “Europe/London”, but still wants to see times and dates according to >>> their local timezone. >> Oh, it's a bigger issue than "wants to see times." It's a major >> future event/scheduling issue. >> >> Because when it comes to scheduling, it's most ideal to set future >> events in localtime, and not UTC. Because most future events are to >> localtime, not UTC, especially if the offset changes for the Zone >> between now and the event. >> >> Both Lotus and Microsoft got caught by that in 2007. It's sad, >> because being on the Zoneinfo list for over a decade, you'd be >> surprised how much Zones do very much change! In some nations, they >> don't even set their daylight savings date until the weeks before! >> >>> The “timedatectl” command (or for that matter the “tzconfig” command) >>> doesn't seem to support that idea. >> Wholly inapplicable. That's only for setting /etc/localtime, RTC, and >> related, system-wide stuff. >> >> Again, user environment has never been standardized well for Zoneinfo. >> Which is why, if at all possible, either avoid setting TZ, or set it >> to UTC. Even today, even if the shell works correct with a Zoneinfo >> path -- of which there are variations (e.g., most Solaris releases >> prefer if you preface it with colon, ":") -- there are so many >> applications that will disagree. >> >> This has been a long-standing issue that the standards bodies have not >> been able to address and proliferate well. >> >> -- bjs > > > > -- > Alessandro Selli <[email protected]> > Tel. portatile: 340.839.73.05 > VOIP SIP: [email protected] > Chiave firma PGP/GPG signing key: B7FD89FD > Chiave crittografia PGP/GPG encrypting key: A6023DD5
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
