[tz] incorrect timezone info from tar files

[Brian Inglis]

> On 2019-12-02 11:59, Benjamin Weiser wrote:
>> On Monday, December 2, 2019 9:49 AM, Jon Skeet wrote:
>>> On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser wrote:
>>>> I’d like to report your downloads for the following Time Zones from
>>>> this URL on your site are out of date: https://www.iana.org/time-zones>>>> For instance Europe/Istanbul moved to UTC 3 permanently in September of
>>>> 2016 and no longer follow DST.
>>>> I will place the correct times first, and then the incorrect IANA
>>>> times second. Highlighted in orange have the incorrect time zone
>>>> information (0 means there is no DST, 1 means they follow DST)

>>> Could you clarify /exactly /how you derived your table, in terms of the
>>> IANA data?
>>> If you look at 
>>> https://nodatime.org/tzvalidate/generate?version=2019c&zone=Europe/Istanbul
>>> - which is generated from IANA data - it shows DST changes stopping in
>>> September 2016, just as you said.
>>> Likewise if you look at the current source data, you'll see the same
>>> result.
>>> I suspect this is a problem of data interpretation rather than anything
>>> else.

>> I will have the dev take a look at why his tools are not refreshing the data
>> correctly. I do see the correct values in the links that you provided and in
>> the download I mentioned. We were in the process of consolidating two teams that
>> were sourcing TimeZones from different data sources. The team using IANA was
>> claiming they were refreshing, so something must be going wrong with their tools
>> as you suggested.

With a history of 215 code and 248 data releases over 27 years so far, with info
from hundreds of contributors across the globe every year, fed downstream to all
major systems, distros, vendors, orgs, projects, products, and languages,
feedback is similarly global, continuous, and timely; sometimes waiting weeks or
months for official government confirmation in announcements, decrees, laws,
orders, or regulations.

The list continually fields complaints that the data is out of date, when it is
the poster's systems, distros, vendors, orgs, projects, products, or languages
that are more likely to be out of date.
As this list and tzdb are one of the global sources for providing correct
localized date/time internationally, your other sources are most likely incorrect.
A simple search of the list archives would provide confirmation that the change

When applications are wrong, 90%+ of the time it is a specification or
implementation issue (and 90%+ of implementation issues are array or memory
access issues).
More likely your devs are trying to interpret the timezone data, rather than
just using it through the provided API, trying to be "efficient" or "smart",
rather than correct internationally.

The calendar, date/time, time zone/DST, locale, and internationalization APIs
are somewhat involved and unwieldy because people, languages, and countries are
inconsistent and difficult to deal with, especially if you want to do so correctly.

Treating date/time stamps and associated APIs as anything other than opaque
objects and methods leads to disaster, as we found during Y2K remediation.

In subsequent and current development, idiots still use two digit years and
non-standard opaque storage and I/O formats (anything other than mm/dd/yyyy in
US and yyyy-mm-dd everywhere; up to 2012 most others were uninterpretably
ambiguous during the first 12 days each month), pick apart dates, times,
subfields, try to convert them independently, and are surprised how often the
results are bad!

Developers should take whatever they have as a date/time stamp or string and
pass it through an opaque wrapper function, that calls all the standard API
functions in the required order, including any locale and internationalization
interpretations, to produce the complete desired result date/time stamp or
string. All other approaches are doomed to failure!

Many, often humorous, articles for developers have been written of the form: do
you know how many (one of:) seconds, minutes, hours, days, weeks, months, years,
centuries, millenia, are in (some larger measure of time), and the answers are
always as abstruse, obscure, and varied, as similar articles about how many
ounces were in bushels or barrels, when such units were in common use.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.