On 2018-01-26 00:15, Robert Elz wrote:
From: Meno Hochschild <mhochschild@gmx.de> Date: Fri, 26 Jan 2018 05:49:44 +0100 Subject: Re: [tz] [english 100%] Re: [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Irelandchange Why do we need all this? That is, what end-user real applications actually use any of this data, what do they use it for, and what do they really need (or want) ?
2) we display this in our UI. Why? Because it is available. If you stopped displaying it, would it matter? Users would notice the difference and complain. Would it actually affect how your application works, or how the users use it? Not really, no.
If (2) there ends with a "yes" answer, then exactly how the data is used, what its needed for, and what would break without it (this is assuming it is all working perfectly, ignore what happens if things change and cause errors, for now anyway) is what would be useful to know.
Maybe it will turn out that all of this really is important (to at least some class of end users and the apps they use) in which case we need to go ahead and find solutions to the problems that are known to exist now. I don't think I have ever seen one. Ever. But of course, I don't have experience with *everything* that exists (nor even most of it) so I might just have missed something, somewhere.
Embedded devices sold outside the US or native English speaking world, especially the EU, CN; like: mobiles, tablets, e-readers, non-MS servers and user desktops, control system front ends; international ecommerce and other applications and websites like social media, app stores, banking, and travel: rental vehicle booking systems, hotel reservation systems, airlines, cruise lines, travel agencies; nothing important to anyone ;^> 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. Let's face it, politicians and bureaucrats are just not as creative as nature's production of better fools for testing our fool-proof systems, towards improvement of which our main effort, time, and money should be directed. ;^> We should also bear in mind the IETF's belief in rough consensus and running code, and hum while reviewing RFC7282 and RFC6557/BCP175 ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada