[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Making timezone configuration more modular



For a long time, we used the tzconfig command to select
a system's timezone.  We then dropped that interface in
favor of debconf-based configuration.  While this was
not nearly as convenient or easy to use, it offered the
benefit of internationalized templates, and today the
tzdata templates are translated into 30 languages.

Currently we are sticking strictly to upstream
timezone names, and omitting any aliases or backward
compatibility links.  This has the positive effect
of not cluttering the debconf menus with even more
choices, and the negative effect that people cannot
find the timezone choices they may be used to,
and in many cases users are unaware of which city
corresponds to the timezone in which they live,
are visiting, or are trying to see the local time for.

Users become very passionate about their own
particular timezone issues, whether these are
functional or purely aesthetic.  Upstream tends
to care little for the aesthetic issues, for they
claim quite correctly that they are not mandating
the information we present to the users.

One thing we could do is to decouple the tzdata
package from the selection mechanism; it could
provide a shell-script interface to set the
contents of /etc/timezone and /etc/localtime,
and then an arbitrary number of config-UI packages
could share that interface and let the user choose
between a tzconfig-alike, the current debconf
scripts, and then something else that corresponds
to whatever political statements, spelling styles,
or easily-recognizable zone names that people might
desire.

The downsides would probably be more coordination
work and more translation work.

Alternately we could just come up with a single
new system to force upon everyone, or bandaid-patch
tzdata any time anyone complains.

Thoughts?


Reply to: