Guy Harris wrote:I don't know what the lowest layers of Windows (NT) use (I don't have any "NT Native API" documentation handy), but the Windows API offers GetSystemTimeAsFileTime(), which supplies tenths-of-microseconds-since-the-FILETIME-epoch ("January 1, 1601 (UTC)", using the proleptic Gregorian calendar and some probably-proleptic form of UTC), so it can do UTC as well. ... Caché runs atop Windows, assorted UN*Xes, and OpenVMS. SYS$GETTIME on VMS supplies "the number of 100-nanosecond intervals since November 17, 1858."
Tom Lane wrote:
In the department of weird epoch reference dates: I have a very distinct recollection that HYDRA/C.mmp[1] ran their system clock in microseconds since Charles Babbage's birthday (26 December 1791). Unfortunately I can't find any evidence other than 40-plus-year-old memory to support that. The C.mmp book cited by Wikipedia describes the clock as being 56 bits wide, which would be plenty for that timespan, but there's nothing in it about the timekeeping convention.
Paul Eggert wrote:
Sydney Lupkin reports in today's Kaiser Health News that Epic Systems, a leading system used for hospital health records, cannot handle DST fallbacks such as Sunday's fallback in the US. Lupkin writes:
'Carol Hawthorne-Johnson, an ICU nurse in California, said her hospital doesn't shut down the Epic system during the fall time change. But she's come to expect that the vitals she enters into the system from 1 a.m. to 2 a.m. will be deleted when the clock falls back to 1 a.m. One hour's worth of electronic record-keeping "is gone," she said.'
Apparently competing systems have similar problems. Lupkin writes that many hospitals plan for Cerner (another major system) to be down after a DST fallback as well. [...]
The moral of this story seems to be: arrange for your medical emergencies to occur some time other than early Sunday in the US.
Paul Eggert wrote:
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".
