Correcting daylight-savings time for central Missouri prior to 1967
I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane. The timezones database appears to assume all Missouri observed daylight savings whenever Chicago, Illinois did. I would like to correct this mistake, but am not clear how to go about doing so. Can the daylight-savings time be set at the state level, then overridden for particular communities? Best regards, Jane Eisenstein
On Nov 23, 2018, at 10:50 AM, Jane Eisenstein <softweave@gmail.com> wrote:
I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane.
The changes didn't show up as attachments to your message; perhaps the mail software dropped them.
I would like to correct this mistake, but am not clear how to go about doing so.
The theory.html file says: The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone with a notable location and records all known clock transitions for that location. 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. Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970. Clock transitions before 1970 are recorded for each timezone, because most systems support timestamps before 1970 and could misbehave if data entries were omitted for pre-1970 transitions. However, the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping. Although some information outside the scope of the database is collected in a file backzone that is distributed along with the database proper, this file is less reliable and does not necessarily follow database guidelines. so we don't guarantee the ability to handle pre-1970 dates and times. If we decide to incorporate a change to handle that, we would presumably end up creating a new tzdb region, (probably) America/Kansas_City, with no DST prior to the point at which they adopted DST, and the same rules as America/Chicago afterwards.
Can the daylight-savings time be set at the state level, then overridden for particular communities?
When using the tz database, daylight-savings time is set at the *region* level; region boundaries are set by time zone and daylight-savings-time rule boundaries, not boundaries of countries or of political/administrative subregions of countries such as states, provinces, prefectures, etc.. So the answer to the question is "not applicable" - they are only set at the state level if a state happens to correspond to a tzdb region.
I hadn’t come across theory.html before, but was able to locate it at ftp://ftp.iana.org/tz/theory.html. It's now clear to me the time zone database was not designed to provide accurate USA daylight savings time information for dates prior to 1970. Unfortunately, some software relies on your data but does not notify users the daylight savings data for dates before 1970 may be inaccurate. I am cc’ing to their developers in hopes they will update their software to include such a notice. Best, Jane Eisenstein
On Nov 23, 2018, at 2:43 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 23, 2018, at 10:50 AM, Jane Eisenstein <softweave@gmail.com> wrote:
I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane.
The changes didn't show up as attachments to your message; perhaps the mail software dropped them.
I would like to correct this mistake, but am not clear how to go about doing so.
The theory.html file says:
The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). The database labels each timezone with a notable location and records all known clock transitions for that location. 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.
Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time, America/Mazatlan which observes Mexican-style DST, and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970.
Clock transitions before 1970 are recorded for each timezone, because most systems support timestamps before 1970 and could misbehave if data entries were omitted for pre-1970 transitions. However, the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping. Although some information outside the scope of the database is collected in a file backzone that is distributed along with the database proper, this file is less reliable and does not necessarily follow database guidelines.
so we don't guarantee the ability to handle pre-1970 dates and times.
If we decide to incorporate a change to handle that, we would presumably end up creating a new tzdb region, (probably) America/Kansas_City, with no DST prior to the point at which they adopted DST, and the same rules as America/Chicago afterwards.
Can the daylight-savings time be set at the state level, then overridden for particular communities?
When using the tz database, daylight-savings time is set at the *region* level; region boundaries are set by time zone and daylight-savings-time rule boundaries, not boundaries of countries or of political/administrative subregions of countries such as states, provinces, prefectures, etc..
So the answer to the question is "not applicable" - they are only set at the state level if a state happens to correspond to a tzdb region.
The Terran Atlas was designed with such warnings in mind. I’m curious, Jane, if you’ve just discovered how time change history is chaotic? I had this reaction in 2010 when I confronted the problem as a result of no longer having access to the ACS atlas as a programmer of astrological software but read through all of Paul’s notes in the data portion. The reality is that it is much worse than most people are aware. Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history. For instance, the ACS Atlas reports that Tylers Corner, NY has had a different standard than Mexico and Pulaski (depending upon the time of year back in the early 1900’s). My fathers family knows the residence (the only one at the time) at Tyler’s Corner (the Stock residence) which is a farming family that my father sometimes had dealings with back in the 40’s and 50’s. He’s still alive and said that he thinks that time was fairly standard in this area across the whole region. Our family has farmed hundreds of acres in this region since 1809. But trying to be accurate about time when nobody except the railroads cared is impossible to do. My guess is that when meetings were set up, they’d say "arrive when you get up”. The stock residence probably used a wind up clock which will be off by 10 - 15 minutes a day (my father still uses one of those to this day).
I’m just glad I personally researched my own pre-1970 birth date and know DST was not in effect. Caveat emptor.
On Nov 23, 2018, at 4:41 PM, Zoidiasoft Tech <zoidsoft@gmail.com> wrote:
The Terran Atlas was designed with such warnings in mind. I’m curious, Jane, if you’ve just discovered how time change history is chaotic? I had this reaction in 2010 when I confronted the problem as a result of no longer having access to the ACS atlas as a programmer of astrological software but read through all of Paul’s notes in the data portion. The reality is that it is much worse than most people are aware. Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history.
For instance, the ACS Atlas reports that Tylers Corner, NY has had a different standard than Mexico and Pulaski (depending upon the time of year back in the early 1900’s). My fathers family knows the residence (the only one at the time) at Tyler’s Corner (the Stock residence) which is a farming family that my father sometimes had dealings with back in the 40’s and 50’s. He’s still alive and said that he thinks that time was fairly standard in this area across the whole region. Our family has farmed hundreds of acres in this region since 1809. But trying to be accurate about time when nobody except the railroads cared is impossible to do. My guess is that when meetings were set up, they’d say "arrive when you get up”. The stock residence probably used a wind up clock which will be off by 10 - 15 minutes a day (my father still uses one of those to this day).
Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history.
Would it warrant the creation of an additional tz region for them?
On Nov 23, 2018, at 6:56 PM, Phake Nick <c933103@gmail.com> wrote:
Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history. Would it warrant the creation of an additional tz region for them?
Since we all live in the same place, you will end up with multiple zones for the same region depending upon who you count as important. The same would be the case then for the Apache in southern CO, the ethnic Uyghurs in China, etc… If your app is about charting airline arrival and departure times, then using an Amish schedule would be foolish. They use horses for transportation anyway. In my own software, I just add a TMessage (a string list) which takes the julian date as a parameter to warn users about these exceptions. Unfortunately it is far from being all encompassing, but as the user sees enough of these messages through use, it helps to generate the appropriate amount of caution.
Currently the Timezone boundary builder tool have already supported overlapping timezone and applied it to places like Xinjiang China and Jerusalem Israel (Palestine) etc. So overlapping shouldn't be a problem, however in such case extra thought might be needed for tz database ID. 2018-11-24日 08:16, Zoidiasoft Tech <zoidsoft@gmail.com> wrote:
On Nov 23, 2018, at 6:56 PM, Phake Nick <c933103@gmail.com> wrote:
Even now, locally in upstate NY, the Amish are present and form a
significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history.
Would it warrant the creation of an additional tz region for them?
Since we all live in the same place, you will end up with multiple zones for the same region depending upon who you count as important. The same would be the case then for the Apache in southern CO, the ethnic Uyghurs in China, etc… If your app is about charting airline arrival and departure times, then using an Amish schedule would be foolish. They use horses for transportation anyway. In my own software, I just add a TMessage (a string list) which takes the julian date as a parameter to warn users about these exceptions. Unfortunately it is far from being all encompassing, but as the user sees enough of these messages through use, it helps to generate the appropriate amount of caution.
On Nov 23, 2018, at 3:56 PM, Phake Nick <c933103@gmail.com> wrote:
Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history. Would it warrant the creation of an additional tz region for them?
Which time zones and DST rules, other than those specified by a governmental body or similar organization, should the tz data base handle? I could imagine that, in a territory that has more than one body exercising the functions of a government, and in which the two bodies specify a different time zone offset or different DST rules, we might support both (and there might be examples of that). Heck, at least as I read the "asia" file, there's *one* body exercising the functions of a government in the Xinjiang Uygur Autonomous Region, and they recognize both standard PRC time and Xinjiang time. However, I'm not sure that a particular group choosing not to follow DST, *and* also largely choosing not to use computers, would be helped very much by getting their own tzdb region, and people who communicate with them would probably not be helped much, either, as they're probably already pretty much used to shifting time when saying "meet me in town at 2 PM" to members of that group, i.e. if DST is in effect, if you want to meet them when *your* watch says 2 PM, you tell them "meet me in town at 1 PM" (unless members of group do the translation). At least one page, http://amishamerica.com/do-the-amish-use-computers-and-the-internet/, suggests that some Amish use cell phones. I'm not sure whether they'd want it to display their time or their non-Amish neighbors' time - if they use the cell phone largely to deal with non-Amish people, displaying non-Amish time might be preferred. (I'm guessing they prefer feature phones to smartphones.)
Growing up in mid-Missouri in the 50’s and 60’s, it was common knowledge that only large cities observed daylight savings time. The rest of the state was mostly farmland and the farmers didn’t want to use daylight savings time. I only became aware of how uncertain time change history is when I began running across astrology software that uses the tz database. They consistently miscalculate my Columbia, MO August 1950 birth chart due to assuming daylight savings time was in effect. No other astrology software I’ve used has this problem. I would like to be part of the solution, but don’t know how to beyond sharing the Doane information.
On Nov 23, 2018, at 4:41 PM, Zoidiasoft Tech <zoidsoft@gmail.com> wrote:
The Terran Atlas was designed with such warnings in mind. I’m curious, Jane, if you’ve just discovered how time change history is chaotic? I had this reaction in 2010 when I confronted the problem as a result of no longer having access to the ACS atlas as a programmer of astrological software but read through all of Paul’s notes in the data portion. The reality is that it is much worse than most people are aware. Even now, locally in upstate NY, the Amish are present and form a significant part of the population. They never observe DST and are on standard time year around. Most of them have sworn off any form of electricity aynway. Situations like this are quite common in time change history.
For instance, the ACS Atlas reports that Tylers Corner, NY has had a different standard than Mexico and Pulaski (depending upon the time of year back in the early 1900’s). My fathers family knows the residence (the only one at the time) at Tyler’s Corner (the Stock residence) which is a farming family that my father sometimes had dealings with back in the 40’s and 50’s. He’s still alive and said that he thinks that time was fairly standard in this area across the whole region. Our family has farmed hundreds of acres in this region since 1809. But trying to be accurate about time when nobody except the railroads cared is impossible to do. My guess is that when meetings were set up, they’d say "arrive when you get up”. The stock residence probably used a wind up clock which will be off by 10 - 15 minutes a day (my father still uses one of those to this day).
Date: Fri, 23 Nov 2018 20:08:58 -0500 From: Jane Eisenstein <softweave@gmail.com> Message-ID: <D7CF49D1-E8A6-4AA6-A803-A175AA164A75@gmail.com> | I would like to be part of the solution, but don't know how to Best would be to visit whatever local (preferably) large library is around, and look back in (local) newspaper archives for contemporary reports of when summer time started and ended, and anything else related (perhaps when it was starting/ending in other areas, and local news was indicating it would not be applied in ....) kre
I only became aware of how uncertain time change history is when I began running across astrology software that uses the tz database. They consistently miscalculate my Columbia, MO August 1950 birth chart due to assuming daylight savings time was in effect. No other astrology software I’ve used has this problem.
I would like to be part of the solution, but don’t know how to beyond sharing the Doane information.
We’ve known about the Doris Doane collection for a long time. The issue is that the farther back in time change history you go, the more iffy the data. The fog of history encroaches. The TZ database doesn’t try to overstate accuracy and IMO has a reasonable cutoff date of Jan 1, 1970. We can try and be more accurate for time stamps in the past and perhaps the ACS Atlas is better for use in astrological software, but the TZ database wasn’t built for that purpose. There are attempts to expand the format of the TZ data to include time change history pre-unix epoch date of 1970, but the growth of the database will grow exponentially the farther back in time that you go. My guess is that bringing full history all the way back to the onset of standard time circa 1900 (earlier in some areas), would cause the tz database to expand to 10,000+ zones (it’s roughly 470 now). There are approximately 500 researchers subscribed to this group (last I heard from ADO). If we can’t accurately account for that level of depth, then how is a small company of a handful of researchers going to do this? I think it would be better if we set aside confirmation bias and really see the issues, which can’t really be fully understood unless you’ve read through the entire database portion of the TZ data (Pauls notes and notes from other researchers). Take all such information with a large grain of salt.
Here are the scans from:
On Nov 23, 2018, at 1:50 PM, Jane Eisenstein <softweave@gmail.com> wrote:
Missouri daylight-savings time information from the 1990 revision of Time Changes in the U.S.A. by Doris Chase Doane.
On Nov 23, 2018, at 12:25 PM, Jane Eisenstein <softweave@gmail.com> wrote:
Here are the scans from:
On Nov 23, 2018, at 1:50 PM, Jane Eisenstein <softweave@gmail.com> wrote:
Missouri daylight-savings time information from the 1990 revision of Time Changes in the U.S.A. by Doris Chase Doane.
So, at least as I read what they're saying, that would require *several* new tzdb regions for the local regions where DST was observed.
Perhaps. I would have to locate each of the exceptions and see whether any are adjoining. My guess is that many are adjacent to either Kansas City or St. Louis, both of which observed daylight savings time prior to 1966. Adjoining localities could share the same region.
On Nov 23, 2018, at 3:45 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 23, 2018, at 12:25 PM, Jane Eisenstein <softweave@gmail.com> wrote:
Here are the scans from:
On Nov 23, 2018, at 1:50 PM, Jane Eisenstein <softweave@gmail.com> wrote:
Missouri daylight-savings time information from the 1990 revision of Time Changes in the U.S.A. by Doris Chase Doane.
So, at least as I read what they're saying, that would require *several* new tzdb regions for the local regions where DST was observed.
Date: Fri, 23 Nov 2018 15:52:19 -0500 From: Jane Eisenstein <softweave@gmail.com> Message-ID: <7DD1D3F1-2C71-44DB-8794-2967D669D200@gmail.com> | Perhaps. I would have to locate each of the exceptions and see whether any | are adjoining. If you mean geographically, then no, that's not needed. What makes a region is that the clocks set correctly show, and have shown, the same time, alyways, since standardised times were introduced (or for definite inclusion in tzdb, since 1970) If two areas have always had the same local time, they can be represented by the same timezone (and would normally be so unless that looks to be by pure chance with no overriding reason it should be so). If the local time has ever differed (since 1970, and ideally, though we are not there yet, since standardied time) then they should be different zones. kre
On Nov 23, 2018, at 2:17 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
Date: Fri, 23 Nov 2018 15:52:19 -0500 From: Jane Eisenstein <softweave@gmail.com> Message-ID: <7DD1D3F1-2C71-44DB-8794-2967D669D200@gmail.com>
| Perhaps. I would have to locate each of the exceptions and see whether any | are adjoining.
If you mean geographically, then no, that's not needed. What makes a region is that the clocks set correctly show, and have shown, the same time, alyways, since standardised times were introduced (or for definite inclusion in tzdb, since 1970) If two areas have always had the same local time, they can be represented by the same timezone (and would normally be so unless that looks to be by pure chance with no overriding reason it should be so). If the local time has ever differed (since 1970, and ideally, though we are not there yet, since standardied time) then they should be different zones.
So there is no requirement that a tzdb region be a connected space?
On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
So there is no requirement that a tzdb region be a connected space?
I think not. Until last year the border of India and Bangladesh was very frothy with at least one third level enclave (of one country within another country within ...). I wonder if the denizens of the enclaves chose Bangladesh time or India time. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Nov 23, 2018, at 3:05 PM, Steve Allen <sla@ucolick.org> wrote:
On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
So there is no requirement that a tzdb region be a connected space?
I think not.
Hopefully the makers of shape files for tzdb regions have taken that into account.
On 2018-11-23 16:21, Guy Harris wrote:
On Nov 23, 2018, at 3:05 PM, Steve Allen <sla@ucolick.org> wrote:
On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
So there is no requirement that a tzdb region be a connected space? I think not. Hopefully the makers of shape files for tzdb regions have taken that into account.
Check Arizona (AZ), USA - which does not observe DST - Navajo Nation in NE AZ observes DST as it also spans NW New Mexico, SE Utah, SW Colorado and those states observe DST - the Hopi Reservation enclave and its smaller exclaves within Navajo Nation do not observe DST. If these areas are appropriately flagged or displayed, the data should be good. -- 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 Nov 24, 2018, at 11:27 AM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
On 2018-11-23 16:21, Guy Harris wrote:
On Nov 23, 2018, at 3:05 PM, Steve Allen <sla@ucolick.org> wrote:
On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
So there is no requirement that a tzdb region be a connected space? I think not. Hopefully the makers of shape files for tzdb regions have taken that into account.
Check Arizona (AZ), USA - which does not observe DST - Navajo Nation in NE AZ observes DST as it also spans NW New Mexico, SE Utah, SW Colorado and those states observe DST - the Hopi Reservation enclave and its smaller exclaves within Navajo Nation do not observe DST. If these areas are appropriately flagged or displayed, the data should be good.
So those would be the America/Phoenix tzdb region, which should include the non-Navajo Nation parts of Arizona, including the Hopi Reservation, and the America/Denver tzdb region, which should include the Navajo Nation. That means that the America/Phoenix region is not a connected space. This image: https://raw.githubusercontent.com/evansiroky/timezone-boundary-builder/maste... doesn't appear to reflect that; hopefully the timezone boundary builder: https://github.com/evansiroky/timezone-boundary-builder supports regions built by adding arbitrary connected spaces to, and removing arbitrary connected spaces from, an initial connected space. I'll let Deborah Goldsmith address whether Apple's regions (used for the macOS/iOS/etc. location-to-tzdb-region mapping) can, and do, handle this.
Actually it do support union/unconnected space, it is also reflected in the image but you need a magnifying glass to see that (or read the code directly). Also it seems like it only have Hopi reservation enclave but not amy others. 2018-11-25 03:51, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 24, 2018, at 11:27 AM, Brian Inglis < Brian.Inglis@SystematicSw.ab.ca> wrote:
On 2018-11-23 16:21, Guy Harris wrote:
On Nov 23, 2018, at 3:05 PM, Steve Allen <sla@ucolick.org> wrote:
On Fri 2018-11-23T15:00:31-0800 Guy Harris hath writ:
So there is no requirement that a tzdb region be a connected space? I think not. Hopefully the makers of shape files for tzdb regions have taken that into account.
Check Arizona (AZ), USA - which does not observe DST - Navajo Nation in NE AZ observes DST as it also spans NW New Mexico, SE Utah, SW Colorado and those states observe DST - the Hopi Reservation enclave and its smaller exclaves within Navajo Nation do not observe DST. If these areas are appropriately flagged or displayed, the data should be good.
So those would be the America/Phoenix tzdb region, which should include the non-Navajo Nation parts of Arizona, including the Hopi Reservation, and the America/Denver tzdb region, which should include the Navajo Nation.
That means that the America/Phoenix region is not a connected space.
This image:
https://raw.githubusercontent.com/evansiroky/timezone-boundary-builder/maste...
doesn't appear to reflect that; hopefully the timezone boundary builder:
https://github.com/evansiroky/timezone-boundary-builder
supports regions built by adding arbitrary connected spaces to, and removing arbitrary connected spaces from, an initial connected space.
I'll let Deborah Goldsmith address whether Apple's regions (used for the macOS/iOS/etc. location-to-tzdb-region mapping) can, and do, handle this.
Jane Eisenstein wrote:
I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane.
Doane partitions Missouri into about two dozen regions with distinct time zone histories. In contrast, Shanks[1] lists 49 such regions in Missouri. Both authors say Missouri agrees with America/Chicago after 1970 so we haven't needed to create a new zone for any of these regions, under the guidelines Guy Harris mentioned. We've found Shanks to be unreliable, and if Doane (like Shanks) cites no sources it's probably no better than Shanks, and most likely worse. If someone did the legwork to come up with primary sources for Missouri (copies of old newspapers and the like), we could put the resulting data into the 'backzone' file. It'd be some work, though. [1] Shanks TG. The American Atlas. 5th ed. 1990. ACS. https://www.worldcat.org/title/american-atlas-us-longitudes-latitudes-time-c...
Doane lists the attached suggested resources for further research in her book — but does not provide a specific reference for each table item. I’d be satisfied if software that relies on the tz database simply warned users that DST info prior to 1970 may not be correct.
On Nov 23, 2018, at 3:45 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Jane Eisenstein wrote:
I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane.
Doane partitions Missouri into about two dozen regions with distinct time zone histories. In contrast, Shanks[1] lists 49 such regions in Missouri. Both authors say Missouri agrees with America/Chicago after 1970 so we haven't needed to create a new zone for any of these regions, under the guidelines Guy Harris mentioned.
We've found Shanks to be unreliable, and if Doane (like Shanks) cites no sources it's probably no better than Shanks, and most likely worse. If someone did the legwork to come up with primary sources for Missouri (copies of old newspapers and the like), we could put the resulting data into the 'backzone' file. It'd be some work, though.
[1] Shanks TG. The American Atlas. 5th ed. 1990. ACS. https://www.worldcat.org/title/american-atlas-us-longitudes-latitudes-time-c... <https://www.worldcat.org/title/american-atlas-us-longitudes-latitudes-time-c...>
Jane Eisenstein wrote:
I’d be satisfied if software that relies on the tz database simply warned users that DST info prior to 1970 may not be correct.
Any such warning shouldn't be limited to pre-1970 info. Another part of theory.html says "The tz database is not authoritative, and it surely has errors," and this applies to info after 1970 too. Some info we haven't had time to fix, some is disputed, some fixes are waiting for the next release, and some is incorrect info that we simply don't know is incorrect.
On 23/11/2018 21:02, Jane Eisenstein wrote:
Doane lists the attached suggested resources for further research in her book — but does not provide a specific reference for each table item.
I’d be satisfied if software that relies on the tz database simply warned users that DST info prior to 1970 may not be correct.
It's nice to see a fellow data user who has found TZ for much the same reason. I've been banging my head against this brick wall for a number of years now after finding genealogical data that we could not decipher because it did not even reference which version of TZ had been used to create it. At the very least there should be warnings but in addition it would be nice if well researched material was included by default and not relegated to the little used 'backzone' file. Much of my UK material relies on data in there which may or may not be available to the user - with no warning :( -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
participants (9)
-
Brian Inglis -
Guy Harris -
Jane Eisenstein -
Lester Caine -
Paul Eggert -
Phake Nick -
Robert Elz -
Steve Allen -
Zoidiasoft Tech