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

[Paul Eggert]

Guy Harris wrote:
> 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)

As I understand it, Epic's core suite was written in MUMPS (also known as M), 
which stores each timestamp as an integer count of days since 1840-12-31, paired 
with an integer count of seconds since local midnight. Although there are 
facilities to get UTC and timezone-adjusted timestamps, my guess is that they 
were added later and that most code assumes local time, which could help to 
explain the DST problems with that Epic and other EHR companies have (and why 
they can't or won't fix the problems).

The MUMPS zero point 1840-12-31 was chosen to be the end of a leap year for 
convenience in calculations. The leap year 1840 was chosen so that it could 
safely represent the birthday of the oldest person conceivably needing 
healthcare in the US when the timestamp format was effectively standardized for 
MUMPS in 1969. This is according to a letter from James M. Poitras published in 
the "Just Ask!" column of the September 1993 issue of "M Computing"; see:

http://www.faqs.org/faqs/m-technology-faq/part1/