[ Answering multiple people here ] > But, "tzselect" only sends time zone information > to standard output. It doesn't modify any configuration > files.
It's _extremely_ important to understand what Zoneinfo and the concepts behind the Olson database are: http://en.wikipedia.org/wiki/Zoneinfo For the most part, these are the concepts: - Standard Nomenclature: Region/Largest-City - Files Are Self-Contained and Complete History - LSB/FHS: Stored in /usr/share/zoneinfo - Current: System (not user) set in /etc/localtime > You might also want to add the files that > determine whether the system > clock is set to UTC. On Debian/Ubuntu systems, > that's in the > "/etc/default/rcS" file. On Red Hat, > it's in the "/etc/sysconfig/clock" file. That's more PC-centric and making a microcosm out of a single detail. I.e., only on the PC do you really need to worry if the RTC is not set to UTC, because Windows is the only OS that does not. Zoneinfo _assumes_ that the system keeps time on UTC, and then off-sets from it. The fact that the system has to do an "added off-set" because a non-standards-based OS uses another default really shouldn't be something we concern ourselves too terribly much with. ;) Other than "in concept." I.e., different distros address it in different ways, so don't touch those differences. Focus on the commonality. E.g., I'd focus more on /usr/share/zoneinfo and /etc/localtime when it comes to paths. Don't focus on other paths that cannot be nailed down. Another great concept is why a symlink from one to the other doesn't work at boot. HINT: What if /usr is not in the root filesystem? ;) > Yes, debian and redhat use different files to set the > same thing, but these > are for system wide settings that are/could be > different even for other > linux flavors (Gentoo uses /etc/conf.d/clock), LSB/FHS standard: /etc/localtime is the Zoneinfo file for the system's local timezone. That is the file that is then off-set from UTC, which is system time. You can still have a question that talks about the UTC off-set issues with PCs without getting distro-specific. Again, avoid anything that could be distro specific. Otherwise, Zoneinfo is pretty standardized and assumes UTC. It's the non-UTC RTC that causes the problem (not vice-versa ;). > Very true. But, since the exam is mainly focused on Red > Hat and Debian, these are the only two distros that I > mentioned. Focus on Zoneinfo itself. Stick with LSB/FHS where possible. Avoid specifics. You can have a number of solid, detailed, even in-depth objectives around Zoneinfo on its own. Trust me, I fought a number of them back in 2006 when I helped address Zoneinfo for the #1 embedded product in use in the financial/trading industry. You can really throw a lot in there! ;) > Still, you bring up a good point. That is, would there be > enough market demand to create a separate exam for other > distros, like say, Gentoo or Slackware? Argumentative (applies to multiple people). Stay focused on LSB, FHS and Zoneinfo concepts. There's plenty to cover than to focus on minor, conflicting details. Again ... Regardless of what init or config script sets /etc/localtime, it is set in the same place on all systems, according to LSB/FHS. Likewise, any and all Zoneinfo files, or compatibility files, are in /usr/share/zoneinfo, according to LSB/FHS. E.g., a solid question would be whether to use "US/Eastern" or "America/New York", to follow proper convention. > but in all of them you could use the TZ variable to set > the timezone for you, in an user wide way. Yes, to override for the user. But TZ has its issues. It's generally _not_ "good practice" because of those limitations. It should only be used for "short logins." For services and long-term logins, you want to stick with the system timezone, dynamically set by /etc/localtime. I fought the legacy TZ approach quite heavily in the aforementioned, embedded product, because of the issues it caused. ;) > Also true, and that also might be worth adding to the exam > objectives. Also note that TZ is a legacy POSIX approach, and does not offer the dynamic, continuous (backwards and forwards) history that Zoneinfo does. In select areas of the world, Zoneinfo really addresses some rather varying timezone changes. I.e., we're spoiled here in North America, because daylight savings is fixed, with fixed rules. ;) -- Bryan J Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://www.linkedin.com/in/bjsmith -------------------------------------------------------- I don't have a "favorite Linux distro." I use, develop and support community efforts, often built around Linux. Technology and solutions are my focus, not dragging in assumptions, marketing and other concepts which dominate non-community developed software, which I left long ago. _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
