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.