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.

On Thu, 5 Dec 2019 at 02:07, Benjamin Weiser <Benjamin.Weiser@inrix.com> wrote:

I do see a lot of these have recently updated.

I still see an issue with Brazil. Are those to be assumed as updated as well? I’m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo -3:06:28 - LMT 1914

-3:00 Brazil -03/-02 1963 Oct 23 0:00

-3:00 1:00 -02 1964

-3:00 Brazil -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.

-3:00 Brazil -03/-02

No, that just means that since 1964, Sao_Paulo followed the Brazil rules. The Brazil rules have no DST changes after 2019-02-17T02:00:00Z. See https://nodatime.org/tzvalidate/generate?version=2019c&zone=America/Sao_Paul... Jon

Thanks Rodrigo, Do you mind explaining how you would parse America/Sao_Paulo? I see the note acknowledging Daylight Savings was scrapped, but not sure how you are getting that value correctly. We are using a JODA library, and my understanding is it finds the timezone under the ‘Zone’ section, such as America/Sao_Paulo, and finds the bottom most value for the most current timezone. For America/Sao_Paulo it says: -3:00 Brazil -03/-02 Are we not looking in the correct place? In the ‘Rule’ section I don’t see anything that would give me -3:00 without DST. Thanks From: Rodrigo Brüning Wessler <madigo@gmail.com> Sent: Friday, December 6, 2019 12:56 PM To: Benjamin Weiser <Benjamin.Weiser@inrix.com> Cc: Jon Skeet <skeet@pobox.com>; tz@iana.org Subject: Re: [tz] incorrect timezone info from tar files Brazilian time zone rules was updated and released in version 2019b. I'm using this version without issues. On Fri, Dec 6, 2019 at 5:28 PM Benjamin Weiser <Benjamin.Weiser@inrix.com<mailto:Benjamin.Weiser@inrix.com>> wrote: I do see a lot of these have recently updated. I still see an issue with Brazil. Are those to be assumed as updated as well? I’m still seeing, for example in America/Sao_Paulo: Zone America/Sao_Paulo -3:06:28 - LMT 1914 -3:00 Brazil -03/-02 1963 Oct 23 0:00 -3:00 1:00 -02 1964 -3:00 Brazil -03/-02 The last line would indicate that its still following daylight savings, which Brazil scrapped this year. -3:00 Brazil -03/-02 From: Benjamin Weiser Sent: Monday, December 2, 2019 10:59 AM To: Jon Skeet <skeet@pobox.com<mailto:skeet@pobox.com>> Cc: tz@iana.org<mailto:tz@iana.org> Subject: RE: [tz] incorrect timezone info from tar files Thank you Jon, 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. I appreciate the feedback. From: Jon Skeet <skeet@pobox.com<mailto:skeet@pobox.com>> Sent: Monday, December 2, 2019 9:49 AM To: Benjamin Weiser <Benjamin.Weiser@inrix.com<mailto:Benjamin.Weiser@inrix.com>> Cc: tz@iana.org<mailto:tz@iana.org> Subject: Re: [tz] incorrect timezone info from tar files 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnodatime.org%2Ftzvalidate%2Fgenerate%3Fversion%3D2019c%26zone%3DEurope%2FIstanbul&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523354252&sdata=EyV738S01v1f8M%2Bv6W3GWJSsN5Gm85dDGMgkw12wt60%3D&reserved=0> - 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...>, you'll see the same result. I suspect this is a problem of data interpretation rather than anything else. Jon On Mon, 2 Dec 2019 at 17:32, Benjamin Weiser <Benjamin.Weiser@inrix.com<mailto:Benjamin.Weiser@inrix.com>> wrote: Hello, 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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Ftime-zones&data=02%7C01%7CBenjamin.Weiser%40inrix.com%7C6ce9b6589b6c4178083e08d77a8eac54%7C6ad2e4da8c924e588877ed06b8918379%7C1%7C0%7C637112625523364245&sdata=APGcT40OlXZM1HF%2Fty%2FrAV9IbLdxe39xZDdOAuy7BZY%3D&reserved=0> 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) TimeZone UTC Offset ObservesDST IANA_UTC_offset: IANA_ObservesDST: America/Campo_Grande -4 0 -4 1 America/Sao_Paulo -3 0 -3 1 America/St_Johns -3.5 1 -3 1 Asia/Sakhalin 11 0 10 0 Australia/Adelaide 9.5 1 9 1 Australia/Darwin 9.5 0 9 0 Australia/Lord_Howe 10.5 1 10 1 Europe/Istanbul 3 0 2 1 Indian/Cocos 6.5 0 6 0 Pacific/Chatham 12.75 1 12 1 Thanks.

Date: Fri, 6 Dec 2019 21:23:41 +0000 From: Benjamin Weiser <Benjamin.Weiser@inrix.com> Message-ID: <BYAPR14MB30633C1E816B79A2B5935F18E85F0@BYAPR14MB3063.namprd14.prod.outlook.com> What may be confusing here, is that what this says: For America/Sao_Paulo it says: -3:00 Brazil -03/-02 is that for Sao Paulo (for the timezone we call America/Sao_Paulo) the standard offset from UTC is -3:00 (3 hours west of Greenwich), when summer time applies is governed by the "Brazil" rules, and the names of the time (the abbreviations used) are "-03" when it is not summer time, and "-02" when it is summer time (like EST and EDT in the US). That's important, the -03/-02 are *not* UTC offsets, they are labels. A few years ago this might have instead been something like -3:00 Brazil EBRT/EBRST using (most probably not those) invented names for the time in winter/summer. But many of the invented names were removed, and replaced by simple numeric names that indicate what offset is applying - but they are just names (labels), they specify nothing else. That a name exists to label summer time when it applies, does not mean it ever does, and more likely, does not mean it applies any particular year. Those names are used for times in the past when summer time was used (and perhaps again in the future if summer time turns on again.) This is another important thing to remember - time conversions must work correctly for times in the past, not just the time today. If I ask what time it was in Sao Paulo at 11:30 Dec 7 2018 UTC, then I need to get the conversion done knowing that it was summer time then. That summer time is not being used this summer does not mean it was not used last summer, and that the answer to that question would be different if the year requested was 2019 instead of 2018 simply reflects how the rules are different this year than they were last year. The only way to discover if (and if so, when) summer time turns on and off, in this case is to look at the Brazil rules (elsewhere in the same source file). The relevant (recent) rules for Brazil end with (all the comments deleted): Rule Brazil 2008 2017 - Oct Sun>=15 0:00 1:00 - Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - Rule Brazil 2016 2019 - Feb Sun>=15 0:00 0 - Rule Brazil 2018 only - Nov Sun>=1 0:00 1:00 - The first and last of those are the only ones (shown) that enable summer time (there are of course others for earlier years, but they're not relevant here, so I didn't include them). The first (as it indicates) applied from 2008 to 2017. The last applied in 2018 (only). There is no rule there for turning on summer time in 2019, or any later year. The intervening rules are all for when summer time turned off in the various years during this period. The last of those says summer time (the one that started in early November 2018) ended in mid February, 2019 (as it had in most of the years since 2008, just 2012 and 2015 ended a week later) All of this is visible in those Rule lines. After that there is nothing. Summer time turned off in Feb 2019, and never turns on again (and so never needs to turn off again either). That is, until the politicians in Brazil decide to change things again, in which case, after we find out what the new rules will be, we will need a new release of tzdata to contain that new information. The Rules are used because there are many different timezones in Brazil, with different UTC offsets, and different labels to name what the time is called (for whatever that is worth), but they all turn summer time on and off (when they use it at all) according to the same rules - so the rules are specified once, and the zones which have summer time just reference them. Zones in Brazil which never use(d) summer time would not reference the Brazil rules, but simply specify what UTC offset applies, and what to label the time as. There aren't, but could be, some zones in Brazil which used a different set of rules, than the others (turned summer time on and off on different dates). If that were the case, then there would be another set of rules (perhaps "Brazil2" or "Tropical-Brazil" or "Northern-Brazil" depending on what seemed appropriate) to specify those different rules, and the relevant zones would refer to those - that happens in Australia, where the various states do whatever they like in this area, and while they seem to all be in sync right now (for those states which use summer time), they haven't been in the past. So in AU, each state gets its own set of rules (they cannot be combined, ever, regardless of the current rules all being the same, or conversions of times in the past would not be correct). Other zones (not from Brazil), which have their own unique summer time rules, not shared with any other zones, might not bother with separate rules and simply specify the transitions in the zone definition. Unless you are used to reading the tzdb data source files, it is generally best not to try - instead run a tzdb compiler (like zic) and then dump the binary format files, and see when the transitions actually occur. That's a much much more reliable way of verifying the data then guessing at how to interpret the tzdata sources. kre

On Dec 4, 2019, at 6:07 PM, Benjamin Weiser <Benjamin.Weiser@inrix.com> wrote:

I still see an issue with Brazil. Are those to be assumed as updated as well? I’m still seeing, for example in America/Sao_Paulo:

Zone America/Sao_Paulo -3:06:28 - LMT 1914 -3:00 Brazil -03/-02 1963 Oct 23 0:00 -3:00 1:00 -02 1964 -3:00 Brazil -03/-02

The last line would indicate that its still following daylight savings, which Brazil scrapped this year.

No, it doesn't. It says that it's following the "Brazil" rules, which are, in the 2019b and 2019c releases: ... Rule Brazil 2008 2017 - Oct Sun>=15 0:00 1:00 - Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - Rule Brazil 2016 2019 - Feb Sun>=15 0:00 0 - Rule Brazil 2018 only - Nov Sun>=1 0:00 1:00 - which says that (among other things, but I omitted the earlier rules that go back to 1931): on the third Sunday in October 2008-2017, the clocks are set forward to 1 hour ahead of standard time; on the third Sunday in February 2008-2011, the clocks are set backward to standard time; on the fourth Sunday in February 2012, the clocks are set backward to standard time; on the third Sunday in February 2013-2014, the clocks are set backward to standard time; on the fourth Sunday in February 2015, the clocks are set to standard time; on the third Sunday in February 2016-2019, the clocks are set to standard time; on the first Sunday in November 2018, the clocks are set forward to 1 hour ahead of standard time; so they got set to standard time on 2019-02-17 and have not been set forward since - in particular, they were not set forward in November.