Hi guys,
I think the TIMEZONE variable in rc.conf is unnecessary and it causes some problems with other (especially GUI) tools. I'd like to hear what you think about deprecating it. We will still keep the support for it in initscripts, but we will suggest (in the standard rc.conf) to not set it. It will then be up to the maintainer of our installer(s) and documentation to adopt (or not) this suggestion.
I cc'ed the GNOME/KDE/XFCE maintainers as I would be interested to hear if their timezone tools work well with rc.conf (I think not, but I might have missed something). I also cc'ed aif and archboot maintainers. Please forward if you know of anyone who maintains relevant packages that I left out.
Cheers,
Tom
From fd5fd34f8a593710483a204d7a7984f89385e3fa Mon Sep 17 00:00:00 2001
From: Tom Gundersen teg@jklm.no Date: Mon, 16 May 2011 13:17:48 +0200 Subject: [PATCH] timezone: deprecate the TIMEZONE variable
Setting the TIMEZONE in rc.conf is a bad idea for several reasons:
* it requires a reboot before taking effect, for people changing timezone's frequently (this is common if you travel a lot, especially annoying if you have several stop overs in different timezones and want your laptop's clock to be correct) * it is non-standard, so advice/guides that apply to other distro's will not apply to arch * it is non-standard, so gui tools like the ones found in KDE/GNOME will not be aware of the setting in rc.conf, and whatever change they do will be overwritten on next boot. * it is one of the few remaining blockers for ro /etc support in initscripts
For these reasons (and possibly more), we deprecate TIMEZONE from rc.conf, and advice users and developers to clear it and set /etc/localtime directly. However, we do not remove the implementation from the scripts, so the timezone is still set during boot/shutdown if the variable is set.
Signed-off-by: Tom Gundersen teg@jklm.no --- rc.conf | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/rc.conf b/rc.conf index 89ea27e..0fb6472 100644 --- a/rc.conf +++ b/rc.conf @@ -8,11 +8,13 @@ # # LOCALE: available languages can be listed with the 'locale -a' command # DAEMON_LOCALE: If set to 'yes', use $LOCALE as the locale during daemon # startup and during the boot process. If set to 'no', the C locale is used. # HARDWARECLOCK: set to "UTC" or "localtime", any other value will result # in the hardware clock being left untouched (useful for virtualization) # Note: Using "localtime" is discouraged. -# TIMEZONE: timezones are found in /usr/share/zoneinfo +# TIMEZONE: (DEPRECATED) copy timezone from /usr/share/zoneinfo to +# /etc/localtime instead # KEYMAP: keymaps are found in /usr/share/kbd/keymaps # CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US) # CONSOLEMAP: found in /usr/share/kbd/consoletrans @@ -22,7 +24,6 @@ LOCALE="en_US.UTF-8" DAEMON_LOCALE="no" HARDWARECLOCK="UTC" -TIMEZONE="Canada/Pacific" KEYMAP="us" CONSOLEFONT= CONSOLEMAP=
On 05/16/2011 09:28 PM, Tom Gundersen wrote:
Hi guys,
hi, i'm forwarding this on our arch-dev-public ml for higher audience
I think the TIMEZONE variable in rc.conf is unnecessary and it causes some problems with other (especially GUI) tools. I'd like to hear what you think about deprecating it. We will still keep the support for it in initscripts, but we will suggest (in the standard rc.conf) to not set it. It will then be up to the maintainer of our installer(s) and documentation to adopt (or not) this suggestion.
i found that deprecating this option will make the set up a bit more complicated and i don't really want to copy/symlink or run tzselect manually.
I cc'ed the GNOME/KDE/XFCE maintainers as I would be interested to hear if their timezone tools work well with rc.conf (I think not, but I might have missed something). I also cc'ed aif and archboot maintainers. Please forward if you know of anyone who maintains relevant packages that I left out.
gnome is perfectly capable to do this, with or without asking an administrator password. For the later we need some adjustment to polkit rules.
we shouldn't focus only on gnome/kde/xfce since they are fully featured desktop environments and have tools for setting the date/time/.
What about minimal setups, they don't have any tools like that and they need to do it manually and is an additional step that is not needed in my opinion.
From fd5fd34f8a593710483a204d7a7984f89385e3fa Mon Sep 17 00:00:00 2001 From: Tom Gundersenteg@jklm.no Date: Mon, 16 May 2011 13:17:48 +0200 Subject: [PATCH] timezone: deprecate the TIMEZONE variable
Setting the TIMEZONE in rc.conf is a bad idea for several reasons:
- it requires a reboot before taking effect, for people changing timezone's frequently (this is common if you travel a lot, especially annoying if you have several stop overs in different timezones and want your laptop's clock to be correct)
- it is non-standard, so advice/guides that apply to other distro's will not apply to arch
- it is non-standard, so gui tools like the ones found in KDE/GNOME will not be aware of the setting in rc.conf, and whatever change they do will be overwritten on next boot.
- it is one of the few remaining blockers for ro /etc support in initscripts
For these reasons (and possibly more), we deprecate TIMEZONE from rc.conf, and advice users and developers to clear it and set /etc/localtime directly. However, we do not remove the implementation from the scripts, so the timezone is still set during boot/shutdown if the variable is set.
Signed-off-by: Tom Gundersenteg@jklm.no
rc.conf | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/rc.conf b/rc.conf index 89ea27e..0fb6472 100644 --- a/rc.conf +++ b/rc.conf @@ -8,11 +8,13 @@ # # LOCALE: available languages can be listed with the 'locale -a' command # DAEMON_LOCALE: If set to 'yes', use $LOCALE as the locale during daemon # startup and during the boot process. If set to 'no', the C locale is used. # HARDWARECLOCK: set to "UTC" or "localtime", any other value will result # in the hardware clock being left untouched (useful for virtualization) # Note: Using "localtime" is discouraged. -# TIMEZONE: timezones are found in /usr/share/zoneinfo +# TIMEZONE: (DEPRECATED) copy timezone from /usr/share/zoneinfo to +# /etc/localtime instead # KEYMAP: keymaps are found in /usr/share/kbd/keymaps # CONSOLEFONT: found in /usr/share/kbd/consolefonts (only needed for non-US) # CONSOLEMAP: found in /usr/share/kbd/consoletrans @@ -22,7 +24,6 @@ LOCALE="en_US.UTF-8" DAEMON_LOCALE="no" HARDWARECLOCK="UTC" -TIMEZONE="Canada/Pacific" KEYMAP="us" CONSOLEFONT= CONSOLEMAP=
--- El lun 16-may-11, Ionut Biru ibiru@archlinux.org escribió:
De: Ionut Biru ibiru@archlinux.org Asunto: Re: [arch-projects] [initscripts][RFC] deprecating TIMEZONE from rc.conf Para: Cc: "Arch Linux projects development discussion" arch-projects@archlinux.org, "Public mailing list for Arch Linux development" arch-dev-public@archlinux.org Fecha: lunes, 16 de mayo de 2011, 16:21 On 05/16/2011 09:28 PM, Tom Gundersen wrote:
Hi guys,
hi, i'm forwarding this on our arch-dev-public ml for higher audience
I think the TIMEZONE variable in rc.conf is
unnecessary and it causes
some problems with other (especially GUI) tools. I'd
like to hear what
you think about deprecating it. We will still keep the
support for it
in initscripts, but we will suggest (in the standard
rc.conf) to not
set it. It will then be up to the maintainer of our
installer(s) and
documentation to adopt (or not) this suggestion.
i found that deprecating this option will make the set up a bit more complicated and i don't really want to copy/symlink or run tzselect manually.
I cc'ed the GNOME/KDE/XFCE maintainers as I would be
interested to
hear if their timezone tools work well with rc.conf (I
think not, but
I might have missed something). I also cc'ed aif and
archboot
maintainers. Please forward if you know of anyone who
maintains
relevant packages that I left out.
gnome is perfectly capable to do this, with or without asking an administrator password. For the later we need some adjustment to polkit rules.
we shouldn't focus only on gnome/kde/xfce since they are fully featured desktop environments and have tools for setting the date/time/.
What about minimal setups, they don't have any tools like that and they need to do it manually and is an additional step that is not needed in my opinion.
With timezone I have a more strong points:
1) System should use UTC. 2) Daemons should use UTC (logger, cron, ...) 3) TZ should be set per user not system-wide.
Am Mon, 16 May 2011 12:51:30 -0700 (PDT) schrieb Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar:
- TZ should be set per user not system-wide.
I completely disagree. What shall I do in Germany with a US timezone on my system (e.g. log files)?
A system usually resides in one country (timezone) and not in several at once. So it's a system and not a user setting.
Heiko
On 05/16/2011 06:10 PM, Heiko Baums wrote:
Am Mon, 16 May 2011 12:51:30 -0700 (PDT) schrieb Gerardo Exequiel Pozzivmlinuz386@yahoo.com.ar:
- TZ should be set per user not system-wide.
I completely disagree. What shall I do in Germany with a US timezone on my system (e.g. log files)?
I just copy the answer from my other email:
On 05/16/2011 07:08 PM, Gerardo Exequiel Pozzi wrote:
Fixme if I am wrong: So (for logger) during entering/exiting from DST period you will see duplicate entries and "no activity" during one hour.
Having logs in UTC avoid this. Is the task of the program that parses the log to show (if needed) the time in your current timezone.
A system usually resides in one country (timezone) and not in several at once.
True.
So it's a system and not a user setting.
I think in a desktop system, yes. But if you are "server", users wants your timezone (from where are conected) instead of local timezone of the server. Or I am missing something?
Heiko
Am Mon, 16 May 2011 19:29:57 -0300 schrieb Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar:
Having logs in UTC avoid this. Is the task of the program that parses the log to show (if needed) the time in your current timezone.
And what if I parse the log with my own eyes without a software parser? Then I also want to see the local time without calculating the timezone by myself.
I think in a desktop system, yes. But if you are "server", users wants your timezone (from where are conected) instead of local timezone of the server. Or I am missing something?
I guess you're missing something, because on servers the timezone setting is only for the server and this is also located only at one place at a time and the timezone data is used to set the server's timestamps. The users' timezone is usually set at their clients which connect to these servers.
If the server needs to store files from different countries it should set the timezone to UTC anyway I guess.
Heiko
On 05/16/2011 07:58 PM, Heiko Baums wrote:
Am Mon, 16 May 2011 19:29:57 -0300 schrieb Gerardo Exequiel Pozzivmlinuz386@yahoo.com.ar:
Having logs in UTC avoid this. Is the task of the program that parses the log to show (if needed) the time in your current timezone.
And what if I parse the log with my own eyes without a software parser? Then I also want to see the local time without calculating the timezone by myself.
Oh nothing to do (report to upstream :P) No problem, use timezone on logs, just keep in mind the holes and duplicated times, during DST change.
I think in a desktop system, yes. But if you are "server", users wants your timezone (from where are conected) instead of local timezone of the server. Or I am missing something?
I guess you're missing something, because on servers the timezone setting is only for the server and this is also located only at one place at a time and the timezone data is used to set the server's timestamps. The users' timezone is usually set at their clients which connect to these servers.
Depends on client/server of course.
If the server needs to store files from different countries it should set the timezone to UTC anyway I guess.
Naturally, avoinding lots of issues.
Heiko
On Mon, May 16, 2011 at 9:51 PM, Gerardo Exequiel Pozzi
With timezone I have a more strong points:
- System should use UTC.
Then you loose information. System time is already in UTC from the kernel, /etc/localtime provide information about the current timezone as well. I think people would find it surprising if we do something non-standard here.
- Daemons should use UTC (logger, cron, ...)
The daemons know both UTC and the current localtime, so they should know themselves which one to use.
- TZ should be set per user not system-wide.
I don't think it is a good idea to set the TZ as mentioned earlier, but it could be used in special cases if you know what you are doing I guess. Certainly not something to recommend as default though.
Thanks for the feedback!
Cheers,
Tom
On 05/16/2011 06:17 PM, Tom Gundersen wrote:
On Mon, May 16, 2011 at 9:51 PM, Gerardo Exequiel Pozzi
With timezone I have a more strong points:
- System should use UTC.
Then you loose information. System time is already in UTC from the kernel, /etc/localtime provide information about the current timezone as well. I think people would find it surprising if we do something non-standard here.
I agree.
- Daemons should use UTC (logger, cron, ...)
The daemons know both UTC and the current localtime, so they should know themselves which one to use.
Fixme if I am wrong: So (for logger) during entering/exiting from DST period you will see duplicate entries and "no activity" during one hour. For cron its a bit intelligent to avoid a task can be executed two times or zero times.
- TZ should be set per user not system-wide.
I don't think it is a good idea to set the TZ as mentioned earlier, but it could be used in special cases if you know what you are doing I guess. Certainly not something to recommend as default though.
Thanks for the feedback!
Cheers,
Tom
On Tue, May 17, 2011 at 12:08 AM, Gerardo Exequiel Pozzi vmlinuz386@yahoo.com.ar wrote:
On 05/16/2011 06:17 PM, Tom Gundersen wrote:
On Mon, May 16, 2011 at 9:51 PM, Gerardo Exequiel Pozzi
With timezone I have a more strong points:
- System should use UTC.
Then you loose information. System time is already in UTC from the kernel, /etc/localtime provide information about the current timezone as well. I think people would find it surprising if we do something non-standard here.
I agree.
- Daemons should use UTC (logger, cron, ...)
The daemons know both UTC and the current localtime, so they should know themselves which one to use.
Fixme if I am wrong: So (for logger) during entering/exiting from DST period you will see duplicate entries and "no activity" during one hour. For cron its a bit intelligent to avoid a task can be executed two times or zero times.
I would say that if programs use localtime and cannot deal nicely with DST, then that's a bug (they should use UTC directly). It would be wrong to force all daemons to use UTC all the time though.
-t
On Mon, May 16, 2011 at 9:21 PM, Ionut Biru ibiru@archlinux.org wrote:
i found that deprecating this option will make the set up a bit more complicated and i don't really want to copy/symlink or run tzselect manually.
tzselect doesn't actually set the system timezone (only for your current session), but it would be very easy to wrap it in a small shell script that would set the system time based on your choice. This adds the benefit over setting TIMEZONE that it will give you a menu of choices rather than asking you to look it up in the fs.
I cc'ed the GNOME/KDE/XFCE maintainers as I would be interested to hear if their timezone tools work well with rc.conf (I think not, but I might have missed something). I also cc'ed aif and archboot maintainers. Please forward if you know of anyone who maintains relevant packages that I left out.
gnome is perfectly capable to do this, with or without asking an administrator password. For the later we need some adjustment to polkit rules.
Just a clarification: when you set the timezone in gnome, does it overwrite /etc/localtime and update TIMEZONE in rc.conf to match? My experiment with KDE it updates /etc/localtime, but not rc.conf, so at next boot the timezone is reset to the old value.
we shouldn't focus only on gnome/kde/xfce since they are fully featured desktop environments and have tools for setting the date/time/.
My idea was to make sure that all tools that might set /etc/localtime work well with arch (I only mentioned the DE as they are the ones where I know tools exist, there might be more). That means that they either have to be patched to update rc.conf, or that we should make sure not to overwrite the changes they do.
What about minimal setups, they don't have any tools like that and they need to do it manually and is an additional step that is not needed in my opinion.
I'd be happy to include a small command line tool to do this (using tzselect, or the syntax Aaron suggested, or both).
Thanks for your feedback :-)
Tom
Am 16.05.2011 20:28, schrieb Tom Gundersen:
From: Tom Gundersen teg@jklm.no Date: Mon, 16 May 2011 13:17:48 +0200 Subject: [PATCH] timezone: deprecate the TIMEZONE variable
Setting the TIMEZONE in rc.conf is a bad idea for several reasons:
- it requires a reboot before taking effect, for people changing timezone's frequently (this is common if you travel a lot, especially annoying if you have several stop overs in different timezones and want your laptop's clock to be correct)
- it is non-standard, so advice/guides that apply to other distro's will not apply to arch
- it is non-standard, so gui tools like the ones found in KDE/GNOME will not be aware of the setting in rc.conf, and whatever change they do will be overwritten on next boot.
- it is one of the few remaining blockers for ro /etc support in initscripts
There are two ways of setting the time zone: 1) /etc/localtime (global setting) 2) TZ environment variable (per session)
Any application or desktop can decide to override a global setting with the TZ variable! The TIMEZONE in rc.conf provides a way to make sure /etc/localtime is set and up to date (as it is updated during boot). I see no problem with this setting (although I would prefer a symlink instead of a copy - this caused problems in the far past, if I remember correctly).
On Mon, May 16, 2011 at 9:40 PM, Thomas Bächler thomas@archlinux.org wrote:
There are two ways of setting the time zone:
- /etc/localtime (global setting)
- TZ environment variable (per session)
Any application or desktop can decide to override a global setting with the TZ variable!
Using the TZ variable is never a good idea (except if you are using it for debug purposes). The problem is that once your application is started it will not notice if the timezone changes, whereas if you set /etc/localtime it will.
The TIMEZONE in rc.conf provides a way to make sure /etc/localtime is set and up to date (as it is updated during boot).
But it requires you to reboot for the timezone change to take effect. The proper way to change timezone in Arch is now to either set the var in rc.conf and reboot, or set the var in rc.conf and manually copy the file to /etc/localtime as well.
I noticed this problem because I travel a lot, and it is not uncommon for me to have used my laptop in four timezones within 24 hours. As I'm usually in an airport waiting to catch my plane, I want my laptop to show the correct localtime, preferably without too much fuss.
I see no problem with this setting (although I would prefer a symlink instead of a copy - this caused problems in the far past, if I remember correctly).
A symlink would definitely be best. I guess the problem was with a separate /usr partition? I'd be in support of not supporting separate /usr (as other things are already broken, even in initscripts), but I don't see it as urgent so won't be pushing for this...
Thanks for the feedback!
Cheers,
Tom
Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen teg@jklm.no:
I think the TIMEZONE variable in rc.conf is unnecessary and it causes some problems with other (especially GUI) tools.
Since when is it unnecessary and why? And since when does it cause problems with other tools and which problems does it cause? I never had any issues with this, neither with KDE nor with Xfce.
And there are not only GUI tools but also CLI tools which also need a correctly set timezone.
And what's wrong with the current way of setting a timezone? As far as I know this is the standard way of setting a timezone on Linux, at least Gentoo does it the same way since years.
That said it's obvious that there must be a way to set a system wide timezone at boot time. The current method is, btw., much better, since simpler and easier (KISS), than an /etc/rc.d/timezone method.
Heiko
On Mon, May 16, 2011 at 11:25 PM, Heiko Baums lists@baums-on-web.de wrote:
Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen teg@jklm.no:
I think the TIMEZONE variable in rc.conf is unnecessary and it causes some problems with other (especially GUI) tools.
Since when is it unnecessary and why?
The only time you need to set the timezone, is when you actually change timezone. It is therefore not necessary to do this at every boot.
Setting the timezone is done by somehow writing the timezone info to /etc/localtime. The TIMEZONE variable in rc.conf is a convenient way of doing this, but it has some drawbacks. They are caused by two things: the timezone setting in rc.conf is only applied at boot, and other tools are not aware of rc.conf so any changes they make are later ignored.
And since when does it cause problems with other tools and which problems does it cause? I never had any issues with this, neither with KDE nor with Xfce.
To see a problem (as mentioned earlier): change your (system-wide) timezone in KDE, reboot, check timezone. Timezone was reset to whatever was in rc.conf (which was not updated when you updated your timezone in KDE).
Alternatively: set your timezone in rc.conf and observe that it (obviously, if you know how it works) is not applied until next reboot.
And there are not only GUI tools but also CLI tools which also need a correctly set timezone.
Yes, we obviously need a correctly set timezone. The question is how to set it. If there are CLI tools that set the timezone, they will have the same problems as outlined for KDE, unless they are patched to update rc.conf.
And what's wrong with the current way of setting a timezone? As far as I know this is the standard way of setting a timezone on Linux, at least Gentoo does it the same way since years.
As far as I know Gentoo does the same as Arch, I'm not sure what Ubuntu does and Fedora/OpenSuse do what I propose.
That said it's obvious that there must be a way to set a system wide timezone at boot time. The current method is, btw., much better, since simpler and easier (KISS), than an /etc/rc.d/timezone method.
The simplest way is to do nothing at all during boot.
You only need to set the timezone at install and if it actually has changed, in which case you use a tool (gui/cli) or copy by hand to set /etc/localtime.
Cheers,
Tom
Am Mon, 16 May 2011 23:53:16 +0200 schrieb Tom Gundersen teg@jklm.no:
The only time you need to set the timezone, is when you actually change timezone. It is therefore not necessary to do this at every boot.
Well, yes. I remember again.
To see a problem (as mentioned earlier): change your (system-wide) timezone in KDE, reboot, check timezone. Timezone was reset to whatever was in rc.conf (which was not updated when you updated your timezone in KDE).
But usually not in KDE. Doesn't KDE store its timezone setting separately from /etc/localtime?
As far as I know Gentoo does the same as Arch, I'm not sure what Ubuntu does and Fedora/OpenSuse do what I propose.
The simplest way is to do nothing at all during boot.
You only need to set the timezone at install and if it actually has changed, in which case you use a tool (gui/cli) or copy by hand to set /etc/localtime.
From your explanations and if I think about it again, you're indeed right. The timezone (/etc/localtime) indeed needs to be set only once at install.
And if I continue thinking I think I can remember that I needed to symlink or copy the zoneinfo to /etc/localtime manually on Gentoo.
Heiko
On Mon, May 16, 2011 at 11:53 PM, Tom Gundersen teg@jklm.no wrote:
On Mon, May 16, 2011 at 11:25 PM, Heiko Baums lists@baums-on-web.de wrote:
Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen teg@jklm.no:
As far as I know Gentoo does the same as Arch, I'm not sure what Ubuntu does and Fedora/OpenSuse do what I propose.
debian (probably ubuntu), use dpkg-reconfigure which set /etc/localtime with a copy of timezone file.
That said it's obvious that there must be a way to set a system wide timezone at boot time. The current method is, btw., much better, since simpler and easier (KISS), than an /etc/rc.d/timezone method.
The simplest way is to do nothing at all during boot.
You only need to set the timezone at install and if it actually has changed, in which case you use a tool (gui/cli) or copy by hand to set /etc/localtime.
I agree with your analysis tom, dropping timezone from rc.conf and let /etc/localtime as unique refence is a good, kiss and standard decision.
Let upstream tzselect program set current timezone is nice.
Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen teg@jklm.no:
I cc'ed the GNOME/KDE/XFCE maintainers as I would be interested to hear if their timezone tools work well with rc.conf (I think not, but I might have missed something). I also cc'ed aif and archboot maintainers. Please forward if you know of anyone who maintains relevant packages that I left out.
Xfce doesn't have any tool to change/select the timezone.
-Andy
arch-projects@lists.archlinux.org