The manual correctly states that you need to copy appropriate file from /usr/share/zoneinfo to /etc/localtime but does not mention the new requirement that you in addition set timezone in /etc/conf.d/clock Reproducible: Always Steps to Reproduce: 1. Read manual section 7a. 2. 3. Actual Results: No mention of /etc/conf.d/clock Expected Results: Mention setting timezone in /etc/conf.d/clock
*** Bug 170733 has been marked as a duplicate of this bug. ***
Strictly speaking, that isn't a requirement. If you have copied the correct zoneinfo file to /etc/localtime, you don't need to set TIMEZONE in /etc/conf.d/clock. It's a requirement if you have NOT set /etc/localtime correctly. If you set TIMEZONE to "Continent/City" in /etc/conf.d/clock, then TZ will get set to ":Continent/City", and the zoneinfo file in /usr/share/zoneinfo/Continent/City will be used. (However, since /usr/share might not be available at boot time, this is not a good replacement for /etc/localtime (and etc/localtime under chroot jails for daemons like bind)) I propose that /etc/init.d/clock should be fixed to not complain about it being set to Factory when in fact it has been deliberately commented out. That's not the same as leaving TIMEZONE=Factory in /etc/conf.d/clock, and is perfectly legitimate (and preferred, since it doesn't rely on /usr/share always being available). - if [[ ${TIMEZONE:-Factory} == "Factory" ]] ; then + if [ ${TIMEZONE} == "Factory" ]; then
no, you need to make sure the conf.d file is set so that when the timezone-data is updated, the system knows which file to copy over for you
(In reply to comment #3) > no, you need to make sure the conf.d file is set so that when the timezone-data > is updated, the system knows which file to copy over for you Partial automation is IMO worse than none. It doesn't update the etc/localtime in any chroot jails, and may mistakenly leads users to believe their systems have been fully updated when manual intervention may still be required. Also, the whole timezone-data package isn't needed on systems which get their /etc/localtime file or TZ variable through other means, like memory stick systems where saving an additonal few megabytes can be more important, or systems using a manually set global TZ. Having init.d/clock complain at boot about TIMEZONE being set to Factory then seems wrong. Plus, there's no guarantee that the list of files in /usr/share/zoneinfo is going to be stable between releases, nor that the user wants the time on a running system changed immediately (it may require the time to stay the way it is until a maintenance window when ALL servers can be changed at the same exact time), both of which this new functionality depends on. This seems like a 90% solution to me -- makes 90% of users happy, but screws up for 10%.
all of your weird corner cases can be solved by simply allowing TIMEZONE="" ... this means the admin is 100% responsible and any breakage is their own fault
Fixed in the drafts for the upcoming 2007 release.
