From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> Date: Fri, 26 Jan 2018 10:10:07 -0700 Subject: Re: [tz] [english 100%] OpenJDK/CLDR/ICU/Joda issues with Ireland change | Embedded devices sold outside the US or native English speaking world, | especially the EU, CN; like: mobiles, tablets, e-readers, non-MS servers [...] That's just a list of things that would use time and internationalised interfaces. That's not at all useful, or even relevant. What I was asking for is an example of something which uses these time zone name strings for something that matters. And what that use actually is. That is: a real demonstrated example, not a "well there must be something" answer. I live (and have for many years now) in exactly that part of the world, and I've never seen aything that uses the time zone labels, other than stuff like the unix date command, which displays the abbreviation, just because it always has ... not for any particularly good reason. Certainly (and particularly since it gets shoved in before the year, scripts that parse the output from date expect it to be there - the year that follows is clearly useful (even though these days it would be more common to use date's strftime interface and get values that way) so we cannot simply delete it - but we could make it always be XXX or something, and aside from looking a bit ugly, I suspect no-one would really care. (Or we could always replace it with the numeric offset instead, for all zones.) Once again, someone, point me at something that would actually break if this was to be done? We have numeric (+NN etc) values as the abbreviation in quite a few zones now, and no-one has been moaning about their applications failing because of it, or not that I have seen. | It's probably easier (and cheaper!) to (un-)patch the tzdb to conform to | downstream compatibility requirements, than it would be to change all | downstreams to conform to tzdb theoretical requirements, until those | capabilities are actually required somewhere in the real world. That is definitely the wrong approach. That's the "let's bury our heads in the sand and hope it never happens" solution - which is guaranteed to lead to havoc, when (which it seems is really in the past anyway) it does happen. Much better to commence the updates now, while there is less time pressure, and so more time to plan a suitable conversion strategy, then to just do nothing (for now) and hope. kre