On most Linux distributions, the time zone data is in the package called "tzdata". Simply ensure that package is kept updated. As to how to update a package automatically, that is something that varies per Linux distribution. A google search for how your particular Linux distribution handles automatic software updates will help inform you. There is nothing special about updating the tzdata package versus updating to any other package. For example, here is a support article for Ubuntu server: https://help.ubuntu.com/lts/serverguide/automatic-updates.html And a wiki page about Ubuntu desktop: https://wiki.ubuntu.com/SoftwareUpdates#Checking_for_updates_automatically ________________________________ From: tz <tz-bounces@iana.org> on behalf of Jean via tz <tz@iana.org> Sent: Saturday, November 9, 2019 3:51 AM To: tz@iana.org <tz@iana.org> Subject: [tz] uptodate data Hello, I hope i can ask this question here. I am the programmer of a popular freeware astrology program (planetdance). I have been using the data from the Olson database by means of a script using zdump on linux to get me data for a period of years for all timezones. The method works well enough but i find the data is not uptodate. For instance Morocco dropped it's DST in 2018 and zdump still happily reports DST for the next years. I have been looking for a way to get the uptodate Olson data into my program for many hours, also looked at the official way of compiling the data but i fear that is a bit too difficult for me. There are also commercial solutions but as i am not able nor willing to pay 500 / year to a company and a product i don't like so that's out of the question. So i'm asking for help here. Maybe there is some linux distribution that does have an uptodate tzdata? Or any other means? ps. There are other problems, like the America/Chicago timezone which is notorious for giving false results for years before 1970 but i guess it's too much asked, i'd be happy if you could help me with uptodate data. Thanks. Jean -- Greetings from Groningen Netherlands http://jcremers.com <º)))><¸.·´¯`·.¸><(((º> Facebook https://www.facebook.com/groups/planetdancesoftware
On 11/9/19 3:51 AM, Jean via tz wrote:
There are other problems, like the America/Chicago timezone which is notorious for giving false results for years before 1970
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.
On 13.11.19 08:56, Jean wrote:
@Paul and Matt
Thanks both for answering.
@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.
@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. The timezone as listed on astro.com (they are regarded as the standard just as the people from astrolabe) is 6 hours(https://www.astro.com/astro-databank/Dylan,_Bob).
TZ zone America/Chicago covers a large part of the United states and is correct for all towns in it, after 1 january 1970. Before that date, America/Chicago is only sure to be correct for the city of Chicago itself, but not for all the other places in the area covered by the zone. In fact, American Atlas by Thomas Shanks, which is the best source for pre-1970 time zone history in the US, needs 375 tables to represent all the variants of time zone history in this area. Mostly affected states are IA, IL, IN, KY, MN, MO, ND, NE, OK, TN, WI. The same is true for America/New_York Shanks needs 857 different tables to represent time zone history for the area covered by the single TZ zone America/New_York after 1 Jan 1970. Affected states are CT, DE, FL, GA, KY, MA, MD, ME, NC, NH, NJ, NY, OH, PA, TN, VA, VT, WV. They all had 'chaotic' time zone before 1967, when the Uniform Time Zone act went in force. It is hard to compute correct horoscopes, I can tell you.
Jean, Per theory.html <https://data.iana.org/time-zones/theory.html>, "[a]lthough a named location in the tz database stands for the containing region, its pre-1970 data entries are often accurate for only a small subset of that region." In particular, pre-1970 data in America/Chicago is only intended to be correct for Chicago, IL, so timestamps for the example locations you gave (Duluth, MN; Conway, AR; Port Arthur, TX) may of course differ according to local custom at the time. Pre-1970 data is not considered in the scope of the tz project: "Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent." -- Tim Parenti On Wed, 13 Nov 2019 at 03:17, Jean <jc@jcremers.com> wrote:
I forgot to mention, another famous person Joplin, Janis 19/01/1943 09:45:00 Port Arthur TX, United States, 93w57, 29n53, America/Chicago
Olson database gives the same as astrodatabank, 5 hours. This is to show that the results are not consequently wrong. My impression is that the area is so big there are expceptions but i'm a layman so..
On 12/11/2019 21:23, Paul Eggert wrote:
On 11/9/19 3:51 AM, Jean via tz wrote:
There are other problems, like the America/Chicago timezone which is notorious for giving false results for years before 1970
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.
On 11/13/19 11:59 AM, Tim Parenti wrote:
In particular, pre-1970 data in America/Chicago is only intended to be correct for Chicago, IL, so timestamps for the example locations you gave (Duluth, MN; Conway, AR; Port Arthur, TX) may of course differ according to local custom at the time.
Yes. And of course America/Chicago is not the only entry with problems like these. For example, Europe/London is valid only for London (and even then, only for the parts of London that agreed with the L&NW, the Caledonian, and some other railways at the time). If you want to cast horoscopes for Queen Victoria, George Washington, Julius Caesar, Tang of Shang, etc., you'll need to look elsewhere.
PS: Also for your country Netherlands, the zone Europe/Amsterdam is not correct for all towns. We use 9 different tables to represent pre-1946 time zone history for Netherlands. The problem there is the different beginning and end of German occupation in Worldwars I and II, for some small pockets of Dutch area. On 09.11.19 12:51, Jean via tz wrote:
Hello, I hope i can ask this question here. I am the programmer of a popular freeware astrology program (planetdance). I have been using the data from the Olson database by means of a script using zdump on linux to get me data for a period of years for all timezones. The method works well enough but i find the data is not uptodate. For instance Morocco dropped it's DST in 2018 and zdump still happily reports DST for the next years. I have been looking for a way to get the uptodate Olson data into my program for many hours, also looked at the official way of compiling the data but i fear that is a bit too difficult for me. There are also commercial solutions but as i am not able nor willing to pay 500 / year to a company and a product i don't like so that's out of the question. So i'm asking for help here. Maybe there is some linux distribution that does have an uptodate tzdata? Or any other means?
ps. There are other problems, like the America/Chicago timezone which is notorious for giving false results for years before 1970 but i guess it's too much asked, i'd be happy if you could help me with uptodate data.
participants (6)
-
Alois Treindl -
Jean -
Jean -
Matt Johnson-Pint -
Paul Eggert -
Tim Parenti