Epochryphal

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

Previously, previously, previously, previously, previously.

Tags: , ,

19 Responses:

  1. MattyJ says:

    MUMPS! Yikes! I had no idea. And here I was worried about all the Cobol and Fortran code keeping the money in my bank account safe.

    For you kids born after 1995... You see, Cobol and Fortran used to be ...

    • Cat Mara says:

      Ha ha, "used" to be. Fool! That is not deade which can eternal compile! Behold! If you sayest ye verse in ANSI X3 his Booke thrice each Roodmass ye Thinge will breed outside ye trappe frame Iä Iä

      (Compile LAPACK from source some time. Still a lot of Fortran in there)

    • tfb says:

      Chances are very high that the program that forecasts the weather for you is written in Fortran. Fortran is deeply horrible, but for numerical code it's less deeply horrible than, say, C. (There doesn't seem to be any language in which numerical code is not horrible, perhaps because people with taste in programming languages don't write numerical code.)

  2. Steve Holmes says:

    I once built a proprietary T1/E1 analyzer for a previous employer that was pretty popular internally, we chose August 16, 1977 for creation time. That's the date that Elvis left the building.

  3. Zygo says:

    I had to take a break and stop reading after "In M, the current date and time is contained in a special system variable, $H (for "HOROLOG")."

    Horolog.

    Then I had to take another break after Googling "horolog".

    A little later on: "In a Boston meeting in Fall 1972 Bruce Waxman of NIH told the audience in no uncertain terms that if they wanted to get NIH money for their computer projects they damned well better be using MUMPS, that NIH was not interested in reinventing THAT wheel, thank you. MUMPS took off."

    And now we know how that disaster happened.

    • Cat Mara says:

      Modern programmers: Ha, MUMPS, how could anyone use something like that? Syntactically-significant whitespace! Weakly-typed schemaless persistence! It is to laugh.
      Also modern programmers: My CoffeeScript-based distributed hashtable, let me show you it
      (Reaches top of Hacker News, stays there)

  4. Stephen says:

    Hey! Still programming in Mumps here. 27 year "career" and counting.

  5. Nathan Williams says:

    November 17, 1858 is a great epoch. It's connected to the Julian day system traditionally used by astronomers - specifically, it's Julian day 2400000.5. 2400000 to make the number of days after that small enough to fit in the 18-bit halfword of an IBM 704 in 1957, and 0.5 to shift from noon-based to midnight-based (pesky astronomers, not wanting day numbers to change in the middle of their observation sessions).

  6. Aidan Kehoe says:

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

    That is possibly the most reasonable epoch of any calendar I've ever seen! In that it has a reasonable reason for its choice. And the actual problems documented are implementors' bad decisions, rather the original decision-makers' bad decisions.

  7. nooj says:

    It's utterly incomprehensible that idiotic executives create these kinds of problems with terrible software development practices. "Oh, wow, and nobody could have seen this coming, but we threw away some of your data again." Guys: YOU HAD ONE JOB!

    I've seen physician groups perpetuate this kind of idiocy with poor standards of their own. In all cases, they formed a committee with the task of "Execs have already decided to switch over to an electronic medical record (EMR) system, without even investigating options. Which one will we use?" instead of "Here is an extensive list of our needs and desires. Are there any EMR systems which mostly match these needs, and in what manner and to what extent do they match?"

  8. WildcatMatt says:

    If I ever get to write software that allows me to define an arbitrary epoch, I will use November 5, 1955.

Leave a Reply

Your email address will not be published. But if you provide a fake email address, I will likely assume that you are a troll, and not publish your comment.

You may use these HTML tags and attributes: <a href="" title=""> <b> <blockquote cite=""> <code> <em> <i> <s> <strike> <strong> <img src="" width="" height="" style=""> <iframe src="" class=""> <video src="" class="" controls="" loop="" muted="" autoplay="" playsinline=""> <div class=""> <blink> <tt> <u>, or *italics*.

  • Previously