EHRs and Daylight Saving Time

So I had noticed that whenever it was time to "fall back" for daylight saving time, our hospital's EHR would have downtime.  I always had assumed this was sort of a coincidence, or maybe that the downtime was a 'change the battery in your smoke detector' kind of event.  But then I read a brief article in Becker's (https://www.beckershospitalreview.com/ehrs/daylight-saving-time-stumps-ehrs-5-things-to-know.html).  And it occurs to me that my hospital's EHR has been shutting down during the fall back overlap because it is unable to handle daylight saving time change.

A quick review of areas that use daylight saving time (DST): at some point during the spring, the clocks will "spring forward" and skip over the entire 1 AM hour, going from 12:59 to 02:00.  This is the 'GAP', and represents the start of DST.  This does not seem to cause a problem with EHRs.

On the other hand, at one point during the fall, the clocks will "fall back".  When the clocks hit 2 am, they go back to 1 am.  In other words, 1:59 AM is followed by 1:00 AM.  This is the 'OVERLAP', and represents the end of DST. This is when apparently many Epic and Cerner systems schedule a downtime.  Per the article, those systems that don't have downtime have the expectation that any observation/result value entered in during that time won't persist.

There is really no excuse for this.  There are a number of software libraries relating to time that can adequately deal with this.  Java version 8 integrated a modified version of the Joda-Time library, which makes this type of issue fairly trivial.  (FYI, the solution in Java speak is to make the timestamps for observations and other important values based on an 'Instant' rather than a 'LocalDateTime'.  The 'Instant' can be represented by the number of milliseconds that have elapsed since Jan 1, 1970 00:00:00 GMT.  There is no ambiguity here.  The EHR software should convert the Instant into a LocalDateTime for display.  And when there is an overlap, the software can even append the time with either 'DT' or 'ST'.  If the EHR is receiving external messages in local time (which it really should not be), it can convert these to instants using the current time zone.

And to put things into perspective, Tesla has software than can essentially drive a car for you.  This is an incredibly intricate system that utilizes state of the art image recognition coupled with complex algorithms to decide the automobile's next move.  EHRs cannot handle inpatient diabetes management, despite discrete structured data (blood glucose values).  And they apparently can't handle daylight saving time changes.