<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Arial">@Paul and Matt<br>
<br>
Thanks both for answering.<br>
<br>
@Matt, when i try to update tzdata it says it is already up to
date. My impression was that it was not, because of the Morokko
2018 switch. But that assumption seems false. I read you are still
debating about Morokko.<br>
<br>
@Paul, it's a long story and an important one for me because many
people find it unforgiving if software in my field has errors in
it's timezone atlas. Since i discovered the trick with zdump it's
a lot better but not perfect. As said, America/Chicago is
notorious, over the years i had many reports of wrong timezones
there, a notable one is the birth of Dylan, Bob 24 May 1941
21:05:00 Duluth MN, United States, 92w06, 46n47, America/Chicago</font><font
face="Arial">. <br>
The timezone as listed on astro.com (they are regarded as the
standard just as the people from astrolabe) is 6 hours</font><font
face="Arial"><font face="Arial"> (</font><font face="Arial"><font
face="Arial"><a class="moz-txt-link-freetext" href="https://www.astro.com/astro-databank/Dylan,_Bob">https://www.astro.com/astro-databank/Dylan,_Bob</a>)</font></font>.
<br>
</font><font face="Arial"><font face="Arial"><br>
But the database gives 5 hours. </font><br>
/usr/share/zoneinfo/America/Chicago Sun Apr 27 07:59:59 1941 UT =
Sun Apr 27 01:59:59 1941 CST isdst=0 gmtoff=-21600<br>
/usr/share/zoneinfo/America/Chicago Sun Apr 27 08:00:00 1941 UT =
Sun Apr 27 03:00:00 1941 CDT isdst=1 gmtoff=-18000<br>
/usr/share/zoneinfo/America/Chicago Sun Sep 28 06:59:59 1941 UT =
Sun Sep 28 01:59:59 1941 CDT isdst=1 gmtoff=-18000<br>
/usr/share/zoneinfo/America/Chicago Sun Sep 28 07:00:00 1941 UT =
Sun Sep 28 01:00:00 1941 CST isdst=0 gmtoff=-21600<br>
<br>
There are many more examples like this. I regret not having
collected them else i could have listed them, one more recent
example is this birth given to me by the man's wife.<br>
23/07/1963 20:03:00 Conway AR, United States, 92w27, 35n05,
America/Chicago<br>
Same case, it should be 6 hours but it's listed as 5.<br>
<br>
Lately i was mailing with a collegue and for what it's worth, he
says he also felt America/Chicago is notorious, he told me he had
been investigating time zones on his own in various states in that
area and made many corrections. As this is just hear-say i can't
comment on the validity of his claims, but my experience is along
the same.<br>
<br>
I regret not being able to present more data to backup my
experience, and i sincerely hope this is not seen as criticism to
your excellent work.<br>
<br>
Thanks for your time.<br>
Jean<br>
</font><br>
<div class="moz-cite-prefix">On 12/11/2019 21:23, Paul Eggert wrote:<br>
</div>
<blockquote type="cite"
cite="mid:08aae027-d908-1fe6-e4ec-856c2f2ab02f@cs.ucla.edu">On
11/9/19 3:51 AM, Jean via tz wrote:
<br>
<blockquote type="cite">There are other problems, like the
America/Chicago timezone which is notorious for giving false
results for years before 1970
<br>
</blockquote>
<br>
Although Matt addressed your other points, I'm curious about this
one. In what sense is tzdb's America/Chicago "notorious" for being
wrong? I used Google to search for '"America/Chicago" false
results' and the only hits I came up with were downstream bugs
(e.g., in PHP installation, or in mistaken use of Python
primitives), not bugs in tzdb itself.
<br>
<br>
</blockquote>
</body>
</html>