Bug#688318: tzdata packages updates consistently cause /etc/timezone to be reset to an undesirable value
Hi,
On Sun, 2023-01-08 at 16:28 +0000, alyandon@hotmail.com wrote:
> January 6, 2023 2:33 PM, "Benjamin Drung" <bdrung@debian.org> wrote:
>
> >
> > It tend to prefer option one (for consistency), but I can see that users
> > might find option two easier for them.
> >
> > --
> > Benjamin Drung
> > Debian & Ubuntu Developer
>
> It is certainly a confusing UX but I’ve long since given up fighting it and
> use American/Chicago (or whatever the city name based timezone is) as the
> timezone.
>
> However, I can state (as an American) that if I walk up to someone on the
> street and ask them what timezone we are in they are going to reply Central,
> Mountain, Eastern, Pacific, etc and not Chicago, Denver, New York, Los
> Angeles, etc. It's just not a way people think about timezones here vs the
> rest of the world I suppose?
>
> Regardless, the real confusion has always been that tzdata package updates
> aren't changing anything about the America/*, US/* timezones so why is it
> touching my /etc/timezone at all? As a developer in a previous life, I
> assume some sort of call to is being made to a validation function that is
> resolving the symlink based path to the real path?
>
> For what it is worth, I do generally prefer consistency as well.
So for an easy solution, I will change debian/tzdata.config to not
change the US/* timezones to their America/* counterparts.
Maybe in the long run we might change from selecting area -> city to
area -> country -> location (in your case: Americas -> United States ->
Central (most areas)), but this kind of selection has its own kind of
problems that need to be resolved.
--
Benjamin Drung
Debian & Ubuntu Developer
Reply to: