This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Removing locale timezone information 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]