possible error or new zone?
Hi, been years, please check out Asia/Dushanbe zone, either a typo or strange new zone? DST/+05/+06. Included is file I hope you find helpful. It's what helped me spot the oddity.
Steven Abner wrote:
please check out Asia/Dushanbe zone, either a typo or strange new zone? DST/+05/+06.
"New" relative to what? The data entries for Asia/Dushanbe itself haven't changed since 2016-08-21. Also, the file you sent is not part of the distribution. I don't know its format, or why it indicates that Dushanbe is unusual. If it helps, to2050.tzs (which you can generate by downloading the tzdb distribution) says the following about Dushanbe's time history, in 'zdump -i' format: TZ="Asia/Dushanbe" - - +043512 LMT 1924-05-02 00:24:48 +05 1930-06-21 01 +06 1981-04-01 01 +07 1 1981-09-30 23 +06 1982-04-01 01 +07 1 1982-09-30 23 +06 1983-04-01 01 +07 1 1983-09-30 23 +06 1984-04-01 01 +07 1 1984-09-30 02 +06 1985-03-31 03 +07 1 1985-09-29 02 +06 1986-03-30 03 +07 1 1986-09-28 02 +06 1987-03-29 03 +07 1 1987-09-27 02 +06 1988-03-27 03 +07 1 1988-09-25 02 +06 1989-03-26 03 +07 1 1989-09-24 02 +06 1990-03-25 03 +07 1 1990-09-30 02 +06 1991-03-31 02 +06 1 1991-09-09 02 +05 Perhaps the program you used to generate your file was flummoxed by the 1991-03-31 transition. It is an unusual transition, as it's a simultaneous switch of standard-time offset and DST flag, such that wall clock time didn't change. But this is a valid transition.
On 25 Feb 2019, at 3:42 AM, Paul Eggert wrote:
"New" relative to what? The data entries for Asia/Dushanbe itself haven't changed since 2016-08-21.
My apologies, relative to back when initial creation, and was tz list bug reporting (iana just took over tz). This was not your mistake! This was my error handling "new" timezone formats, relative to when you did not use literals/rule based "FORMAT"s with std/dst packed, and numeric values in that field. Again, my bad, I'm sorry. Thanks for spotting my bug.
On 25 Feb 2019, at 3:42 AM, Paul Eggert wrote:
Also, the file you sent is not part of the distribution. I don't know its format, or why it indicates that Dushanbe is unusual.
It showed it as unusual because it is the only case where a 'literal' , "RULES" is defined as '-' or a "SAVE' time, with the STD/DST defined in the "FORMAT" field. I've created a patch to my code to handle the break from normal. The file i sent is in your usual tzXXXXx type style, '#' signal comments, 'Link' as link, etc.. The one difference is the 'Abbr/' to inform the parser it is not a standard zone, but an abbreviation for other 'unix'-type functions to handle the identification of strings that use abbreviations in the time string. It also serves as the "America" in "America/New_York", for example. Most of the comments in the link are gmtoffsets, with the years it applies to a given linked zone. Here is revised file after the handling of the exception. Please use for however you wish, trash or information.
participants (2)
-
Paul Eggert -
Steven Abner