[tz] Epic fail for DST fallback in hospital health records

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Mon Nov 5 05:27:27 UTC 2018


On 2018-11-04 19:11, Guy Harris wrote:
> On Nov 4, 2018, at 5:59 PM, Guy Harris wrote:
>> So it's probably just that Epic never got DST handling right.
> Back in 1979, UNIX wasn't as big a platform that sort of application as it
> is now; if they started on VMS (I don't know whether it had a "get the time
> in UTC" API back then) or on MVS (I'm not sure what it offers), maybe using
> local time was a more obvious choice, but you'd still think they'd know that
> stuff does happen at hospitals between 1 AM and 3 AM on Sunday, so...

[Open]VMS provides a 64 bit time with 100ns resolution from the MJD epoch of
1858-11-17, but the update frequency and accuracy depends on interval timer
frequency, which may be as low as 100Hz/10ms.

IBM S/390 (System z) STCK stores a 64 bit time with a resolution of 1/4096us
from the NTP epoch 1900-01-01, updated with a frequency equivalent to
incrementing bit 51 (big endian) every us.

Most TZ and DST issues result from app designers and/or implementors thinking
they understand what systems should do during changeovers, and trying to
implement it themselves, possibly undoing the correct behaviour of a tested
time/zone/DST handling library.

Regulators ensure that the electrical power industry has had a good handle on
dealing with local times and 23-25 hour days for decades.

OTOH my Motorola PVR broadcast schedule/cable program guide properly showed two
periods from 01.00-02.00; but a European sports series broadcast after the
switch skipped recording the first hour Sunday morning early-ish local time!

-- 
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.


More information about the tz mailing list