Request RE: academic research question re: TZ database
Hello. I am a clinical biochemist and not well versed in handling the TZ database. I am investigating a software problem related to hospital patient data management that appears to be triggered when the software encounters a patient record with a date-of-birth that coincides with a historic daylight saving time Spring transition date. Through this investigation I have learned many details about the history of daylight saving time, but I often question the reliability of sources of information. It appears that many use the tz database as a source of truth. I am seeking assistance to query the tz database to determine the entries in the database for Area /Location America/Regina to determine the (1) daylight saving time Spring transition date and (2) daylight saving time Spring transition hour from 1900 to 1966. I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database. I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions. I am uncertain if it is appropriate to ask for this type of assistance on this discussion group. Thank-you very much, regards, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan
On 2020-01-08 12:49, Andrew Lyon wrote:
I am a clinical biochemist and not well versed in handling the TZ database. I am investigating a software problem related to hospital patient data management that appears to be triggered when the software encounters a patient record with a date-of-birth that coincides with a historic daylight saving time Spring transition date. Through this investigation I have learned many details about the history of daylight saving time, but I often question the reliability of sources of information. It appears that many use the tz database as a source of truth.
I am seeking assistance to query the tz database to determine the entries in the database for Area /Location America/Regina to determine the (1) daylight saving time Spring transition date and (2) daylight saving time Spring transition hour from 1900 to 1966. I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database. I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions.
I am uncertain if it is appropriate to ask for this type of assistance on this discussion group.
Attached is the output from zdump -V America/Regina that shows the current (2019c) tz data for America/Regina. Problems are often that tz data is not up to date, or data has been converted using some older data for storage, and is now being converted using newer data for display, or is using something internal to the database which may have any of those problems. Systems that do not use tz data, like older proprietary systems and Windows, may assume the current year's rules applied to every year, or not handle rules at all, and only assume local time, so there may be no accurate way of standardizing any historical entries. -- 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 1/8/20 11:49 AM, Andrew Lyon wrote:
It appears that many use the tz database as a source of truth.
Ouch. As we say in big letters, "The tz code and data are by no means authoritative." <https://data.iana.org/time-zones/tz-link.html#changes>
I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database.
Yes, tzdb says the 10 years 1930/1934 and 1937/1941 all did that, as can be seen from the extract Brian emailed.
I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions.
As Brian mentioned, tzdb has these two transitions for 1918: Sun Apr 14 08:59:59 1918 UT = Sun Apr 14 01:59:59 1918 MST Sun Apr 14 09:00:00 1918 UT = Sun Apr 14 03:00:00 1918 MDT Sun Oct 27 07:59:59 1918 UT = Sun Oct 27 01:59:59 1918 MDT Sun Oct 27 08:00:00 1918 UT = Sun Oct 27 01:00:00 1918 MST However, there's a good chance these data entries are incomplete for Regina. It's also possible that the entries for 1930/1941 are wrong. For details, please read the commentary for Regina in the northamerica file. Here's the current development version: https://github.com/eggert/tz/blob/master/northamerica
Hi Andrew, Regarding the software problem you're seeing, it's quite possibly a result of using a language or API in which dates -- like 2020-01-09 -- are represented as localized datetimes at midnight -- like 2020-01-09 at 00:00 in America/Regina. This is a pervasive class of bugs that affects JavaScript programs for users in Brazil and Chile in particular. JavaScript because the language's builtin Date representation is a datetime (and the ubiquitous moment library isn't so careful with it), and Brazilian and Chilean users because until recently their time zones had midnight spring forwards. Here's a particularly illuminating example of this class of bugs: https://github.com/airbnb/react-dates/issues/776. Hope that helps you track down your software issue. Scott Kilpatrick https://typesandtimes.net <http://typesandtimes.net> On Wed, Jan 8, 2020 at 8:07 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 1/8/20 11:49 AM, Andrew Lyon wrote:
It appears that many use the tz database as a source of truth.
Ouch. As we say in big letters, "The tz code and data are by no means authoritative." <https://data.iana.org/time-zones/tz-link.html#changes>
I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database.
Yes, tzdb says the 10 years 1930/1934 and 1937/1941 all did that, as can be seen from the extract Brian emailed.
I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions.
As Brian mentioned, tzdb has these two transitions for 1918:
Sun Apr 14 08:59:59 1918 UT = Sun Apr 14 01:59:59 1918 MST Sun Apr 14 09:00:00 1918 UT = Sun Apr 14 03:00:00 1918 MDT
Sun Oct 27 07:59:59 1918 UT = Sun Oct 27 01:59:59 1918 MDT Sun Oct 27 08:00:00 1918 UT = Sun Oct 27 01:00:00 1918 MST
However, there's a good chance these data entries are incomplete for Regina. It's also possible that the entries for 1930/1941 are wrong. For details, please read the commentary for Regina in the northamerica file. Here's the current development version:
Thank-you both Paul and Scott for your insight. I will modify my language in the future about calling the tz database a source of truth. Our local problem and software crash occurred on Android devices interfaces with a large database system (the SCC Soft Computer 'Softlab' system). It appears that if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default. Midnight to 00:59:59 is the hour moved forward for daylight saving time 1930-41, so a birth hour of midnight does not exist in UT. It is likely that the Android system was running a JavaScript code and we are seeking help from the manufacturer to confirm that in the error logs available to the manufacturer. We may never know all the details, but it is an interesting and somewhat querky observation that could occur in any timezone with a history of using daylight saving time a sometime in the past ~100 years. regards, Andrew From: "Scott Kilpatrick" <skilpat@gmail.com> To: "Paul Eggert" <eggert@cs.ucla.edu> Cc: "lyoncatch" <lyoncatch@shaw.ca>, "tz" <tz@iana.org> Sent: Thursday, January 9, 2020 7:08:41 AM Subject: Re: [tz] Request RE: academic research question re: TZ database Hi Andrew, Regarding the software problem you're seeing, it's quite possibly a result of using a language or API in which dates -- like 2020-01-09 -- are represented as localized datetimes at midnight -- like 2020-01-09 at 00:00 in America/Regina. This is a pervasive class of bugs that affects JavaScript programs for users in Brazil and Chile in particular. JavaScript because the language's builtin Date representation is a datetime (and the ubiquitous moment library isn't so careful with it), and Brazilian and Chilean users because until recently their time zones had midnight spring forwards. Here's a particularly illuminating example of this class of bugs: [ https://github.com/airbnb/react-dates/issues/776 | https://github.com/airbnb/react-dates/issues/776 ] . Hope that helps you track down your software issue. Scott Kilpatrick [ http://typesandtimes.net/ | https://typesandtimes.net ] On Wed, Jan 8, 2020 at 8:07 PM Paul Eggert < [ mailto:eggert@cs.ucla.edu | eggert@cs.ucla.edu ] > wrote: On 1/8/20 11:49 AM, Andrew Lyon wrote:
It appears that many use the tz database as a source of truth.
Ouch. As we say in big letters, "The tz code and data are by no means authoritative." < [ https://data.iana.org/time-zones/tz-link.html#changes | https://data.iana.org/time-zones/tz-link.html#changes ] >
I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database.
Yes, tzdb says the 10 years 1930/1934 and 1937/1941 all did that, as can be seen from the extract Brian emailed.
I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions.
As Brian mentioned, tzdb has these two transitions for 1918: Sun Apr 14 08:59:59 1918 UT = Sun Apr 14 01:59:59 1918 MST Sun Apr 14 09:00:00 1918 UT = Sun Apr 14 03:00:00 1918 MDT Sun Oct 27 07:59:59 1918 UT = Sun Oct 27 01:59:59 1918 MDT Sun Oct 27 08:00:00 1918 UT = Sun Oct 27 01:00:00 1918 MST However, there's a good chance these data entries are incomplete for Regina. It's also possible that the entries for 1930/1941 are wrong. For details, please read the commentary for Regina in the northamerica file. Here's the current development version: [ https://github.com/eggert/tz/blob/master/northamerica | https://github.com/eggert/tz/blob/master/northamerica ]
On 1/9/20 6:15 AM, Andrew Lyon wrote:
if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default.
If the birth hour is unknown you might be better off defaulting to noon than to midnight. First, noon is likely closer to the actual birth hour.[1] Second, you'll avoid some of these software glitches. [1] https://www.cdc.gov/nchs/products/databriefs/db200.htm
On 2020-01-09, at 14:39:58, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 1/9/20 6:15 AM, Andrew Lyon wrote:
if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default.
If the birth hour is unknown you might be better off defaulting to noon than to midnight. First, noon is likely closer to the actual birth hour.[1] Second, you'll avoid some of these software glitches.
Indeed. I don't know if this is relevant: https://pubs.opengroup.org/onlinepubs/9699919799/functions/mktime.html#tag_1... RETURN VALUE The mktime() function shall return the specified [local] time since the Epoch encoded as a value of type time_t. If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1 [CX] and set errno to indicate the error. Does this refer to times during the spring-forward hour? Should mktime() then return the nearest boundary and set errno? There's an unfortunate design choice since time_t is generally regarded as signed (citation needed) and (time_t)-1 might represent 1969-12-31 23:59:59. The programmer must check errno. -- gil
On 2020-01-09 14:39, Paul Eggert wrote:
On 1/9/20 6:15 AM, Andrew Lyon wrote:
if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default.
If the birth hour is unknown you might be better off defaulting to noon than to midnight. First, noon is likely closer to the actual birth hour.[1] Second, you'll avoid some of these software glitches.
That may be true for the 41 states of the US sampled, where most births are likely to be in hospitals, records may be accurate, and births may be induced to occur when staff are available, indicated by the reports of peak periods; however: "Noninduced vaginal deliveries had the most even distribution across the hours of the day, fluctuating close to the average of 4.2%." The other 9 states may be more rural and the distribution more even. In the rest of the world, where doctors, midwives, or families are likely to have to deal with births as and when they happen, a random time of day will be as accurate. However, dealing with noon (or 0400-2200) local time means you should never have to worry about changes. -- 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.
Assuming even distribution and not considering time changes/DST, the difference between recorded time and the actual time of birth will be at most 12 hours if you use noon, but up to 24 hours if you use midnight (born at 23:59, but recorded as 00:00). That would make the average difference (again, assuming even distribution) 6 hours for noon, but 12 hours for midnight. On Thu, Jan 9, 2020 at 3:01 PM Brian Inglis <Brian.Inglis@systematicsw.ab.ca> wrote:
On 2020-01-09 14:39, Paul Eggert wrote:
On 1/9/20 6:15 AM, Andrew Lyon wrote:
if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default.
If the birth hour is unknown you might be better off defaulting to noon than to midnight. First, noon is likely closer to the actual birth hour.[1] Second, you'll avoid some of these software glitches.
That may be true for the 41 states of the US sampled, where most births are likely to be in hospitals, records may be accurate, and births may be induced to occur when staff are available, indicated by the reports of peak periods; however:
"Noninduced vaginal deliveries had the most even distribution across the hours of the day, fluctuating close to the average of 4.2%."
The other 9 states may be more rural and the distribution more even.
In the rest of the world, where doctors, midwives, or families are likely to have to deal with births as and when they happen, a random time of day will be as accurate.
However, dealing with noon (or 0400-2200) local time means you should never have to worry about changes.
-- 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.
Thank-you Paul. I agree that when the birth-hour is unknown that it could be assigned to a time other than midnight to 00:59:59 or 02:00 to 03:00 to avoid most DST transition problems. We looked into the possibility of changing that default time ourselves, but it appears to be in protected code by the software manufacturer. We are working with the manufacturer to avoid the problem in a future version of the software. We have not heard if the manufacturer will alter the default birth hour to noon or another time. The article you linked on birth hours is very interesting. Most of our problem patients had birth dates between 1930 and 1941 and were likely born without modern interventions that are mostly scheduled during daytime hours. regards, Andrew From: "Paul Eggert" <eggert@cs.ucla.edu> To: "lyoncatch" <lyoncatch@shaw.ca> Cc: "Scott Kilpatrick" <skilpat@gmail.com>, "tz" <tz@iana.org> Sent: Thursday, January 9, 2020 3:39:58 PM Subject: Re: [tz] Request RE: academic research question re: TZ database On 1/9/20 6:15 AM, Andrew Lyon wrote:
if the hour of birth is unknown (for patients born 1930-41), that a birth hour of midnight is assigned as a default.
If the birth hour is unknown you might be better off defaulting to noon than to midnight. First, noon is likely closer to the actual birth hour.[1] Second, you'll avoid some of these software glitches. [1] https://www.cdc.gov/nchs/products/databriefs/db200.htm
On 2020-01-10 07:15, Andrew Lyon wrote:
I agree that when the birth-hour is unknown that it could be assigned to a time other than midnight to 00:59:59 or 02:00 to 03:00 to avoid most DST transition problems. We looked into the possibility of changing that default time ourselves, but it appears to be in protected code by the software manufacturer. We are working with the manufacturer to avoid the problem in a future version of the software. We have not heard if the manufacturer will alter the default birth hour to noon or another time.
Most systems I worked on had such values as parameters in a database table for system parameters and/or business rules indexed by a key value such as TIME_OF_DAY_BIRTH_TIME_DEFAULT. Suggest this as a more flexible solution to your vendor.
The article you linked on birth hours is very interesting. Most of our problem patients had birth dates between 1930 and 1941 and were likely born without modern interventions that are mostly scheduled during daytime hours.
As the article stated, non-induced vaginal births occurred with a flat distribution around the clock. -- 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.
participants (6)
-
Andrew Lyon -
Ben Turner -
Brian Inglis -
Paul Eggert -
Paul Gilmartin -
Scott Kilpatrick