Re: Removing locale timezone information

[Paul Eggert <eggert at cs dot ucla dot edu>]

keld@keldix.com wrote:
> So glibc has no way of making quick corrections appear in distros?
> I think most other critical software has a path to have eg security fixes
> happen very fast in distros.

It's typically harder to update glibc than to update time zone data.  This is 
partly a matter of size (glibc's files are an order of magnitude larger than 
tzdata's), and partly a matter of release engineering (changing tzdata has far 
fewer security and reliability implications than changing glibc does).  We don't 
want to treat every minor daylight-saving rule change with the same urgency and 
thoroughness as we treat a serious security bug in glibc.  And this is why most 
(perhaps all) GNU/Linux distributions have decoupled tzdata from glibc.

> even for the minority users having just a dozen or so likely
> TZ specs to choose from is a good improvement from having
> to choose from a long list of TZs  or even choosing by clicking on a map,
> as previously explained.

I doubt whether the improvement would be worth the hassle of implementing it. 
Even 'tzselect' wouldn't benefit much, and I expect that the fancier selectors 
would benefit even less as nowadays geoselection is often seamless.

Let me give an example to help put this in context.  Currently 'tzselect' asks 
the user for continent and then country, and then it asks for which time zone in 
that country.  A sample interaction is attached as the first attachment.

If there were an easy way tzselect could ask glibc "What country am I in?" from 
a shell script, tzselect could skip the first two questions asking for continent 
and country, and could simply ask the user to confirm the glibc setting. 
Although that would be a nicety, it's not a high-priority one: nobody has asked 
us for this nicety in two decades of tzselect use.

If in addition glibc locales had the extra information you're proposing, 
tzselect could also derive its third question from that extra information, 
presumably in a localized form rather than tzselect's English-only form (though 
if you look at the transcript you'll see that the "English-only" data is 
stylized and contains many proper names and abbreviations that should be 
reasonably useful to a non-English speaker).  This could be nicer for the user, 
but it would be a pain to maintain and typically geoselection is good enough and 
is considerably easier to maintain as the geo data is locale-agnostic.

For a dumb example of geoselection as implemented in tzselect, see the second 
attachment.  The more-commonly used selectors that can use geo information or 
graphical selection can do a much better job than tzselect does here, and these 
programs wouldn't benefit much from any extra information in glibc locales.

I'm not saying that the extra information would be useless, only that the few 
applications that might use it are so specialized that there are good software 
engineering reasons to put this information into some other package (CLDR, say) 
rather than into glibc.

Attachment: tzselect-example.txt
Description: Text document

Attachment: tzselect-geoexample.txt
Description: Text document