tz database update on a publication & thank-you.
Several months ago I posted queries about the tz database to this discussion list as I investigated a series of errors triggered in software used to order and report clinical laboratory tests in our hospital network. Our main software system uses universal time for date& time of birth a recently added peripheral system (based on Android OS, and Java Joda-time that relies on the tz database) that triggered the peripheral system to freeze every few weeks. Investigation revealed that there were 10 years (between 1935 and 1945) in the America/Regina tz time zone data where the transition to daylight saving time occurred at midnight on spring transition dates. If our hospital (which is in the America/Regina time zone) encountered patients born on one of those spring daylight savings time transitions dates 1935-1945, the system froze, because the hour of birth was usually unknown and was assigned to midnight local time by default, and midnight local time on those dates does not map back to universal time. A software patch was quickly developed by the software provider and this susceptibility is now avoided. I understand now that this type of situation is well known to members of this group. I want to pass on a 'thank-you' to the tz database community for their helpful messages as this case was investigated. A description of this investigation was published today in the Journal of Applied Laboratory Medicine: "No Lab Tests" When You Are Born in The Twilight Zone: A Clinical Informatics Case Report. [ https://pubmed.ncbi.nlm.nih.gov/32728691/ | https://pubmed.ncbi.nlm.nih.gov/32728691/ ] best wishes, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan, SK, Canada
Thank you for the heads-up. I submitted a note about this to the RISKS Digest <https://catless.ncl.ac.uk/Risks/> as I think your takeaways deserve wider circulation. I particularly liked the suggestion to use test-patient data with birthdays near DST transitions.
On 7/30/20 9:19 AM, Paul Eggert wrote:
Thank you for the heads-up. I submitted a note about this to the RISKS Digest <https://catless.ncl.ac.uk/Risks/> as I think your takeaways deserve wider circulation.
That note was published yesterday, here: Eggert P. Hospital lab tests delayed by "Twilight Zone" births. RISKS digest 32(16). 2020-07-30. https://catless.ncl.ac.uk/Risks/32/16#subj9
"Paul" == Paul Eggert <eggert@cs.ucla.edu> writes:
On 7/30/20 9:19 AM, Paul Eggert wrote:
Thank you for the heads-up. I submitted a note about this to the RISKS Digest <https://catless.ncl.ac.uk/Risks/> as I think your takeaways deserve wider circulation.
Paul> That note was published yesterday, here: Paul> Eggert P. Hospital lab tests delayed by "Twilight Zone" births. RISKS Paul> digest 32(16). 2020-07-30. https://catless.ncl.ac.uk/Risks/32/16#subj9 A related issue that came to my attention a couple of years ago is that of America/St_Johns, which until 2011 had a DST transition one minute _after_ midnight, resulting in non-contiguous days on the backward transition. (There are a few other historical examples of such zones.) At least Chile (America/Santiago) and, last I looked, some other South American timezones still have transitions at exactly midnight. -- Andrew.
On Thu 2020-07-30T09:30:50-0600 Andrew Lyon hath writ:
A description of this investigation was published today in the Journal of Applied Laboratory Medicine: "No Lab Tests" When You Are Born in The Twilight Zone: A Clinical Informatics Case Report. [ https://pubmed.ncbi.nlm.nih.gov/32728691/ | https://pubmed.ncbi.nlm.nih.gov/32728691/ ]
For the sake of the software and that article I point out that the nothing that could be called UTC existed before 1960, the term UTC was not used until 1965, and not generally known until the mid 1970s. For years in the 1930s the concept of converting time to UTC is barren. The term UT itself was not endorsed by the IAU until 1928, and not commonly used before the 1960s when the Greenwich observatory was no longer active to provide GMT. -- 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 https://www.ucolick.org/~sla/ Hgt +250 m
Date: Thu, 30 Jul 2020 09:27:27 -0700 From: Steve Allen <sla@ucolick.org> Message-ID: <20200730162727.GA30196@ucolick.org> | For the sake of the software and that article I point out that the | nothing that could be called UTC existed before 1960, All that's fine, but shouldn't really matter. There was nothing called a "metre" before the late 18th century, but it is still reasonable to measure the distance between the earth and the moon (or other bodies) from millions of years ago, or the heights of ancient mountains, in metres. The fact that it wouldn't have been called that (and even would have resulted in a different numeric value using some other scale which might have existed at the time) doesn't really matter. For the data in question, the minor differences between GMT and UTC, and even the various different UT and UTn's, and even TAI, don't matter either - birth times would have been set by either looking at someone's watch, or a wall clock, and the chance of those actually being "correct" (within a minute or two, or three) aren't great (would not have been great in the mid 20th century - even for doctors who could afford expensive timepieces). So, I wouldn't really get all pedantic and complain that a time in 193x/194x couldn't possibly be UTC, as UTC didn't exist then .. what it means is the time it would have been in UTC (or close enough for the purpose) had it existed back then (and it has existed longer than the software that generates these values I assume). kre ps: I still believe it is a big mistake to ever convert times expressed in local time into some other timebase, and store that, instead of storing the local time, and the timezone information. The local time is the recorded absolute value, which will never change - even if someone later realises that the offset from UTC (or GMT) that's in the database happened to be incorrect and fixes it. But if you've stored just the UTC (or GMT) version, you no longer really know whether that came from the old bad data or the new fixed version (especially if you're not keeping a very close watch on every change to the database - and even moreso if updates are automated and just happen without anyone really being aware of it).
On Jul 30, 2020, at 6:41 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
... ps: I still believe it is a big mistake to ever convert times expressed in local time into some other timebase, and store that, instead of storing the local time, and the timezone information. The local time is the recorded absolute value, which will never change - even if someone later realises that the offset from UTC (or GMT) that's in the database happened to be incorrect and fixes it. But if you've stored just the UTC (or GMT) version, you no longer really know whether that came from the old bad data or the new fixed version (especially if you're not keeping a very close watch on every change to the database - and even moreso if updates are automated and just happen without anyone really being aware of it).
True, assuming the common case where the original time reading was from a clock set to local time. In some cases people would be using clocks set to another standard, such as GMT or the time of some other standard meridian. If you're looking at timestamps from the chronometer era of sailing, the reference time is that of the chronometer, which is set to GMT, or Paris time, or Washington time, etc., depending on the ship. Similarly, astronomical records might be given in GMT. Or even local sidereal time, which really makes things fun. paul
On 31/07/2020 00:51, Paul.Koning@dell.com wrote:
On Jul 30, 2020, at 6:41 PM, Robert Elz<kre@munnari.OZ.AU> wrote:
... ps: I still believe it is a big mistake to ever convert times expressed in local time into some other timebase, and store that, instead of storing the local time, and the timezone information. The local time is the recorded absolute value, which will never change - even if someone later realises that the offset from UTC (or GMT) that's in the database happened to be incorrect and fixes it. But if you've stored just the UTC (or GMT) version, you no longer really know whether that came from the old bad data or the new fixed version (especially if you're not keeping a very close watch on every change to the database - and even moreso if updates are automated and just happen without anyone really being aware of it). True, assuming the common case where the original time reading was from a clock set to local time. In some cases people would be using clocks set to another standard, such as GMT or the time of some other standard meridian. If you're looking at timestamps from the chronometer era of sailing, the reference time is that of the chronometer, which is set to GMT, or Paris time, or Washington time, etc., depending on the ship.
Similarly, astronomical records might be given in GMT. Or even local sidereal time, which really makes things fun.
I can into this as the result of trying to sort out historic data that had been 'normalised' but nobody had recorded the critical piece of information ... what version of TZ data had been used to normalize it. It was FURTHER complicated because the 'local time' of the server hardware had been used as part of the process again without any record of what set of rules was actually used! Totally accept these days that the recorded data should be the recorded time and SEPARATELY record the LOCATION where the time was recorded. Even today there are arguments about just what 'timezone' is being used locally :( so it would be helpful to record the 'timezone' as a third piece of data. But the other part of the jigsaw is still to run any international web based system on UTC so that the 'local time' of a server does not come into the equation. When I am posting to some forums that still don't understand the problem they give a post time I do not recognise and when looking back through emails times can be out of sync. And they still assume the 'timezone' provided by my browser is a timezone when it's only ever a current offset ... TODAY it is more than likely that the time of birth of a baby will be recorded electronically ... on a computer system ... where several local times are being used and the sequence of records are best served by using UTC as a secure sequential base. Then the fun of a second twin being born 58 minutes before the first is just a local abnormality :) That and moving the local clock to record a different birthday becomes a little more difficult ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
On 2020-07-30 15:30, Andrew Lyon wrote:
Investigation revealed that there were 10 years (between 1935 and 1945) in the America/Regina tz time zone data where the transition to daylight saving time occurred at midnight on spring transition dates.
typo: it should read "(between 1930 and 1941)". Michael Deckers.
participants (8)
-
Andrew Gierth -
Andrew Lyon -
Lester Caine -
Michael H Deckers -
Paul Eggert -
Paul.Koning＠dell.com -
Robert Elz -
Steve Allen