--- El lun 16-may-11, Ionut Biru escribió:

De: Ionut Biru Asunto: Re: [arch-projects] [initscripts][RFC] deprecating TIMEZONE from rc.conf Para: Cc: "Arch Linux projects development discussion" , "Public mailing list for Arch Linux development" 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.

On 05/16/2011 06:10 PM, Heiko Baums wrote:

Am Mon, 16 May 2011 12:51:30 -0700 (PDT) schrieb Gerardo Exequiel Pozzi:

...

3) 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:

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

On 05/16/2011 07:08 PM, Gerardo Exequiel Pozzi wrote: 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

-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On 05/16/2011 07:58 PM, Heiko Baums wrote:

Am Mon, 16 May 2011 19:29:57 -0300 schrieb Gerardo Exequiel Pozzi:

...

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

-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

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:

1) 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. 2) 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.

...

3) 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

-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1

On Mon, May 16, 2011 at 9:21 PM, Ionut Biru 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

On Mon, May 16, 2011 at 9:40 PM, Thomas Bächler wrote:

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!

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

On Mon, May 16, 2011 at 11:25 PM, Heiko Baums wrote:

Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen :

...

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

On Mon, May 16, 2011 at 11:53 PM, Tom Gundersen wrote:

On Mon, May 16, 2011 at 11:25 PM, Heiko Baums wrote:

...

Am Mon, 16 May 2011 20:28:17 +0200 schrieb Tom Gundersen :

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. -- Sébastien Luttringer www.seblu.net