[tz] Correcting daylight-savings time for central Missouri prior to 1967
guy at alum.mit.edu
Fri Nov 23 19:43:04 UTC 2018
On Nov 23, 2018, at 10:50 AM, Jane Eisenstein <softweave at 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.
More information about the tz