Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Medicine

America Braces For Daylight Saving Time - And Missing Medical Records (usatoday.com) 368

"One hundred years after Congress passed the first daylight saving legislation, more and more people are doubting the wisdom of changing the clocks," writes PBS, noting that it actually makes Americans use more electricity and consume more gasoline.

"If you can find anyone who supports this, they're probably just trolling you," writes Inc magazine's contributor editor, adding "Literally everyone hates it... It's almost impossible to find anyone who still supports this insane, anachronistic idea, which is leftover from a German coal conservation idea during World War I, and our heck-we'll-try-anything panic during the energy crisis of the 1970s." In fact, one study found that while consumer spending increases a bit at the start of daylight savings, it drops a full 3.5 percent in the wrong direction when it ends. (Which will happen tonight in most U.S. states at 2:00 a.m.)

And now USA Today points out that hospital software "still can't handle daylight saving time: Epic Systems, one of the most popular electronic health records software systems used by hospitals, can delete records or require cumbersome workarounds when clocks are set back for an hour -- prompting many hospitals to opt for paper records for part of the night shift. And it happens every year... Dr. Steven Stack, a past president of the American Medical Association, called the glitches "perplexing" and "unacceptable," considering that hospitals spend millions of dollars on these systems, and Apple and Google seem to have dealt with seasonal time changes long ago...

Carol Hawthorne-Johnson, an intensive care unit 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 vital signs she enters into the system from 1 a.m. to 2 a.m. Sunday will be deleted when the clock falls back to 1 a.m. One hour's worth of electronic record-keeping "is gone," she said. Hospital staff have learned to deal with it by taking extra chart notes by hand... Many hospitals use Cerner, another major electronic medical records company. Those hospitals plan for Cerner to be down during the time change, too.

This discussion has been archived. No new comments can be posted.

America Braces For Daylight Saving Time - And Missing Medical Records

Comments Filter:
  • by Anonymous Coward on Saturday November 03, 2018 @11:53PM (#57588334)

    The absolute worst part of DST is the stupid semiannual bitchfest on Slashdot.

    • by Z00L00K ( 682162 ) on Sunday November 04, 2018 @02:25AM (#57588676) Homepage Journal

      DST changes are just a headache, but when you run a computer system then you shall always make sure that timestamps are stored in a "neutral" way by using UTC. What's presented to the user is just a presentation issue in the UI. That's why when coding I always use things like the Unix timestamp or something similar and use a 64 bit integer to be safe. A resolution of milliseconds is usually good enough for the majority of systems.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        DST changes are just a headache, but when you run a computer system then you shall always make sure that timestamps are stored in a "neutral" way by using UTC. What's presented to the user is just a presentation issue in the UI.

        That is more or less a given. The problem is dealing with user input.
        If you are going to record when something was entered then that is fine, there is no reason for the user to input it.
        The complicated part is when you want to input that something happened or should happen at a time that occurs twice.
        Was it during the first or second time that those times occurred?
        Also, the presentation isn't "just a presentation issue".
        "Doctor said we should administer medication every other hour" means that it is necessar

        • by Anonymous Coward

          Also consider the transportation of patients across time zones, which happens more often than DST changes. Same issue really, but it's possible to cross multiple zones by airplane. A dialogue of EDT/EST, CDT/CST, MDT/MST, or PDT/PST (in the US, for example) is then complicated in your manual entry scenario.

          Easiest to record and display everything in UTC. Military uses Zulu time for the same reason.

          The systems also need to handle leap seconds, and I doubt those are handled well; given this thread.

  • UTC people (Score:5, Insightful)

    by plopez ( 54068 ) on Saturday November 03, 2018 @11:55PM (#57588340) Journal

    I don't know how many times as a programmer, QA, team lead, sysadmin, and manager I had to pound the concept of Universal Time Coordinates into programmers heads. As well as ntp. Both are critical in real life applications. This is one of many reasons I have come to look upon most programmers with disdain and disgust.

    • Programmers by and large mostly deserve to be looked on with disgust. Not because of the low quality of their output, although the quality is low, but because they don't actually care.
      • Re: UTC people (Score:5, Insightful)

        by Darinbob ( 1142669 ) on Sunday November 04, 2018 @01:06AM (#57588522)

        A: "Why are you in charge of the design?"
        B: "Because I'm a medical records expert!"
        A: "Do you understand time zones, DST, and all their implications?"
        B: "It's just time, how hard can it be? I'm sure all the junior programmers working on it understand that stuff."

        • by Kaenneth ( 82978 )

          China and India don't use DST.

        • by jd ( 1658 )

          This is precisely why the waterfall method explicitly split requirements gathering, specification and design. Subject-matter experts are great for understanding how to be an expert, but case study after case study showed they only partially understood the logic behind it.

          The specification should not be drawn up by an expert in the subject or an expert in designing, but by someone who can communicate with both and who understands how to describe what the subject expert said in terms the design expert can wor

      • by jd ( 1658 )

        I'm one of those who do care. I share your disgust of those who don't. It's not necessary or helpful.

    • The problem here is that medical software is generally old. Programmers naively expect everyone to update software constantly, which is not feasible when the updates are expensive and require additional training. Doesn't help that a lot times the software chosen is the one that had the lowest bid. People bitch about the cost of medical care, but in reality hospitals and clinics are usually on a shoe-string budget when it comes to big budget items.

      • Re:UTC people (Score:5, Informative)

        by Solandri ( 704621 ) on Sunday November 04, 2018 @02:54AM (#57588730)

        The problem here is that medical software is generally old. Programmers naively expect everyone to update software constantly, which is not feasible when the updates are expensive and require additional training

        It's not an update problem. I help maintain the computers and software for several doctors. HIPAA required all hospitals and private practices to switch to electronic medical records by 2013. That deadline and more recent requirements being phased in (ICD-10 - standardized codes for reasons for a medical visit - was required a couple years back) means all medical software is relatively new or updated recently. Any doctor using software more than about 2 years old (for ICD-10) is operating illegally.

        The fact that the programmers writing this software are using local time instead of UTC is sheer ignorance, laziness, or incompetence. Another scenario I can think of where local time is a problem is if a patient visits their doctor on the east coast, then immediately flies to the west coast and is hospitalized. The west coast hospital will request the electronic records from the doctor on the east coast. Because it takes some time for the doctor's staff to enter and finalize the data from the patient's visit, due to the different time zones some of the data the west coast hospital receives will be timestamped in the future if the software uses local time.

        • by jd ( 1658 )

          If I'm correct that this is an automatic data purge for rollbacks and testing that was left enabled, then flying to the west coast would trigger the deletion of those records.

      • by jd ( 1658 )

        Software of any kind, except maybe Ada Lovelace's, postdates daylight savings. Most US health software I've seen (or written) is Windows-based, XP or later, so is this millennium. There have never been excuses to use wall clock time rather than GMT time. All operating systems have used GMT since the 1970s. Even the military use GMT (Zulu time).

        Even that doesn't explain deletion. If you used the timestamp alone as a key field, you're an idiot who should be forced to watch reruns of BBC's Eldorado, but it's a

    • by raymorris ( 2726007 ) on Sunday November 04, 2018 @01:04AM (#57588516) Journal

      UTC is certainly the right time zone to use where you, for some reason, need to store a human-readable string that represents a time. Most of the time relared problems and bugs aren't solved by storing times as UTC, though.

      The thing is, you can't get your time calculations right when using year-month-day hour-minute-second format. Almost every professional implementation has had bad bugs. Even if you DID get it bug free, we'd break it after you ship it because we change the rules from time to time.

      How many seconds are in a minute?
      It's not always sixty seconds.

      What time comes after 23:59 59, in UTC.
      If you said midnight, as a programmer, you're wrong (sometimes it's 23:59:60 UTC, such as on December 31, 2016).

      The way to store times as as an integer since the epoch. Unix, Linux etc set the epoch at January 1, 1970. The current Unix epoch time is therefore 1541311061. (That's how many seconds have elapsed since the epoch). Any recent choice of epoch is fine, unless your concerned about times centuries ago.

      When you try to store an manipulate times as strings, you end up with crap like time going backwards, which breaks all kinds of things.

      The only sort-of exception is I wouldn't yell at you for using the temporal types in a well-established relational database like MySQL and MS SQL. They do have bugs, and storing it as a number is more accurate, but the Mysql date handling isn't atrocious.

      • by Kaenneth ( 82978 )

        I once had to help someone over the phone with troubleshooting a database system that wasn't handling dates correctly; they were cataloging tombstones.

      • Like Kirk's Star Dates ;)
      • by dwywit ( 1109409 )

        So, serious question here (as I've never had to do it*). How do you manage the birthdate of anyone born before the epoch?

        *I've had to manage "pre-epoch" birthdates, but not on a *nix system. Hint: EBCDIC

      • by Kjella ( 173770 )

        Most of the time relared problems and bugs aren't solved by storing times as UTC, though. (...) sometimes it's 23:59:60 UTC (...) The way to store times as as an integer since the epoch.

        Adding leap seconds is its own source of bugs though, because "same time tomorrow" means one day whether that day is 86400 or 86401 seconds long. You don't want all your 12:00 appointments to become 11:59:59 appointments because you added a leap second. UTC solves 99.9% of all "human scale" time problems from different time zones and DST, not even the people who measure surgery time or how long you've been on anesthetic care about one second and even if they did the clock drift on consumer devices means it'

    • by ceoyoyo ( 59147 )

      Commercial database "programmers" are the worst kind. Well, maybe tied with web developers.

      You'd think you'd have to try to screw up and lose data with something like DST. Timestamps don't change.

    • by jd ( 1658 )

      I've had contempt in the other direction, managers providing incomplete specifications and placing quality last on the list of priorities. Security and robustness weren't on said lists. Mind you, I've had no less contempt for fellow programmers for not bothering. I've seriously considered quitting the profession and becoming a Buddhist monk. It's all nonsense, but at least I would no longer have to live with the constant pain of being around such incompetence.

    • by msauve ( 701917 )
      "the concept of Universal Time Coordinates"

      What do you think "Universal Time Coordinates" are?

      UTC stands for Coordinated Universal Time in English (the acronym itself is a compromise - in French it stands for Temps Universel Coordonne). "Coordinated" as in a group effort, not a geometric position coordinate.

      If you're going to pound something into someones head, make sure you know what you're talking about before doing so.
    • I don't know how many times as a programmer, QA, team lead, sysadmin, and manager I had to pound the concept of Universal Time Coordinates into programmers heads. As well as ntp. Both are critical in real life applications. This is one of many reasons I have come to look upon most programmers with disdain and disgust.

      You can't simply say "Just use UTC"; sometimes, applications must also display what we call "Wall Clock Time", and during the DST switch night, it can lead to strange behavior even in correct applications (e.g. whe a nurse is supposed to perform an action each 30 minutes).

      The simple solution is, of course, to finally ditch DST, which should happen in Europe soon.

      • What you really need is a designator in the user interface that lets you know whether a wall clock time is pre- or post-changing of the clock, and then also train people in the use of it.

    • No offense, but it sounds like you were harping on something without truly understanding the problem. Using UTC is simple, but it doesn't solve most of the awful headaches of dealing with DST.

    • Well, we are often bad at what we do...I was going to post about how I usually just relied on our database and environment variables to keep my time zones right but even that sometimes may not be enough.

      Didn't Apple just have a DST bug with their watch? I didn't read details, but I think I saw headlines. How could they do that? I remember spending way too much time testing stuff just to make sure it handled time changes and it usually did but I do remember a timekeeping system failing miserably right af

    • Doing things in UTC is the way to go.

      The complication is deciding when to convert it to local time, and what that local time should be. For example, you're monitoring someone's activity. Should activity be shown in the person's current local time, at the local time of when the activity took place, or in the local time of the person viewing the activity?

      You have to make it clear who's time you're talking about.

  • Apples watch whose sole purpose is telling time managed to brick for 24-hours recently when Australia changed time. [appleinsider.com]
    • Re: (Score:2, Funny)

      by blindseer ( 891256 )

      Apples watch whose sole purpose is telling time managed to brick for 24-hours recently when Australia changed time.

      If someone is buying an Apple Watch only to tell time then they are doing it wrong.

  • Comment removed based on user account deletion
  • Give someone some LSD tonight and then change the clocks.

  • by bobstreo ( 1320787 ) on Sunday November 04, 2018 @12:17AM (#57588390)

    I have no data cap, because the tzdata updates come hot and fast every time some state, or random country decides to change their participation in how they manage time.

    I just check my phone/computer to set all my dumb appliances (or mechanical clocks) time displays,

  • That can't properly handle the unfortunate, antiquated reality of daylight savings time is written by idiots. The same goes for leap time.

    • Quite often the functionality isn't built in to some systems. I've had to write this stuff a few times, and have had to fix bugs with it in other systems. Today you'd think that with the religious mantra to never write your own code and only use existing libraries that this problem would go away, and yet people still don't even know how to use their basic C library correctly to do this.

      You'd think it was obvious - and yet remember how Windows 95 had you manually ask you if it should change the time twice

    • Re:Any software... (Score:5, Interesting)

      by arcade ( 16638 ) on Sunday November 04, 2018 @02:31AM (#57588682) Homepage

      The problem with Leap seconds is that they are really, really problematic under unix. Unixtime literally doesn't have leap seconds. There are hacks and workarounds, but only that.

      There are only two real solutions:

      1. Get rid of the concept of leap seconds. The earth's rotation will slowly drift out of sync with astronomical time - but only with about a minute per century. Let someone deal with a leap hour in 6000 years time. Having all of society deal with astronomers who don't want to keep track of this on their own is just silly.

      2. Redefine unixtime to include leapseconds. Change the POSIX standard and all other relevant standards to have unix run on TAI instead of UTC. Keep an /etc/leapseconds where all leapseconds are inserted. Let the system time conversion libraries deal with the conversions authoratatively.

      And don't get me started on the hackish fugliness of leap second smearing. Ye gods is that an ugly hack.

      • by jd ( 1658 )

        It's not acceptable to have something defective by design.

        We learned with Y2K that the other person never does their job until they need to panic.

        Do it once, do it right. Leap seconds are not even remotely hard, ignoring them is simply incompetent programming.

        • by arcade ( 16638 )

          Funny.

          The question here is "what's defective"?

          Historically, a second was defined as 1/86400 of a day. It's a good definition. However, we've later decided that since that period isn't absolute, we should rather define the duration of a second.

          So, in 1967 the second was defined to be exactly 9,192,631,770 times the period of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom.

          Now, while that matches up "pretty well" with a day, it doesn

      • by jd ( 1658 )

        Unixtime should not ever be modified. Same reason it should not ever follow daylight savings. Unixtime is absolute. It has to work on all planets and in space.

        Leap seconds are local to planet of origin, so you want a layer between unixtime and local time that handles leap seconds.

        • by arcade ( 16638 )

          Unixtime should not ever be modified. Same reason it should not ever follow daylight savings. Unixtime is absolute. It has to work on all planets and in space

          Get your facts straight. Unixtime doesn't work like that, and that is kind of the problem.

          To illustrate this, in 2016 we had a leap second on Dec 31st. In other words, time went like this:

          Sat Dec 31 23:59:59 UTC 2016
          Sat Dec 31 23:59:60 UTC 2016
          Sun Jan 1 00:00:00 UTC 2017

          However, if look at this with unixtime, we get:

          $ date --utc --date @1483228799 ; date --utc --date @1483228800
          Sat Dec 31 23:59:59 UTC 2016
          Sun Jan 1 00:00:00 UTC 2017

          There is no way to represent the second that happened at Sat Dec 31 23:5

    • by jd ( 1658 )

      The Earth doesn't rotate once in 24 hours, vertically, perfectly on the plane of the solar system. Nor is the solar system a two body system.

      You must change either the definition of a day or the definition of a second. And even then, there are natural variations for which you'll need corrections.

      The universe is messy. The corrections may need to fit a better design, no problems with that, but you will need them.

    • Actually, dealing with DST is incredibly complex in many cases, ditto for leap time. Not only are the rules complex, the right way to handle them is sometimes subjective (i.e. in terms of what you present to users). It's far more complicated than mapping between UTC and local time.

  • by antdude ( 79039 ) on Sunday November 04, 2018 @12:33AM (#57588428) Homepage Journal

    I love the later sunsets at the evenings. ;)

    • Yeah, I’d prefer permanent Daylight Saving over permanent standard time.

      • I don't give a shit as long as they stop the madness of changing the clocks twice a year.

        I accept having to deal with jet lag when I travel, but I should not be required to do so in virtue of staying in one place.

        • I accept having to deal with jet lag when I travel

          Are you really *that* sensitive? Do you absolutely have to go to bed at exactly the same time every night so it doesn't mess you up the day after? I don't get it. I work early hours but I'm a night person so typically during the week I go to bed at 10pm, but Friday and Saturday night I'm usually up till 1-3am. I just don't get what the problem is.

          • I solved the problem by finding a job that's not sensitive to me being an hour late during the ridiculous times in Summer.

      • Actually, it has been proposed to make Daylight Savings Time the standard time everywhere, all year.

        The reason is that even in winter, it gives people more waking daylight hours than Standard Time does.
        • by mark-t ( 151149 )

          The reason is that even in winter, it gives people more waking daylight hours than Standard Time does.

          Not north of about 45 degrees latitude. In the depths of winter, staying on "summer time", the sun wouldn't rise until nearly 9 o'clock or often even later, by which time most people would have had to already endure a sunless morning commute, which in addition to an increased level of danger with children would also have to walk to school in the dark, as well as in potentially cooler temperatures (since

    • And the later sunrises in the morning in Winter? How much do you like to drive to work in pitch black darkness?

  • by Max_W ( 812974 ) on Sunday November 04, 2018 @12:44AM (#57588458)
    the Russian Federation stopped changing clocks. And the EU follows this example in 2019.

    In fact, it is not complicated, - a government makes a decision and publishes it. This is it, the sanity is back.
    • by peppepz ( 1311345 ) on Sunday November 04, 2018 @01:49AM (#57588598)
      It is more complicated than it seems. In the EU, northern countries (who seem to be the ones who actually care) want DST to be always off, while southern countries want it to be always on. So after the switch we might end up with "horizontal timezones" where previously we had no timezone difference at all, and this way incompetent programmers who store dates as strings will cause damage all year round instead of twice a year. In the US it might not be much of a problem because people are already used to different timezones.
    • by Kaenneth ( 82978 )

      Fuck it, I'd vote to re-elect Trump if he abolished DST.

  • Oh look. I don't even have to read the article to know it's shit because I'm a person and I don't hate it.

    Like many, I'd prefer having permanent daylight savings time (an hour more light in the evenings), but having grown up in the north, I know that would've meant waiting for the school bus in darkness each morning, and many parents might not support that. That said, once people get used to it and quit their bitching, they'll probably be fine with it - in the same way there was a huge uproar from smoker
    • by Kaenneth ( 82978 ) on Sunday November 04, 2018 @02:00AM (#57588628) Journal

      *or* they could just change when school starts.

      • *or* they could just change when school starts.

        As studies show they should [cdc.gov] - and as I hope they would if a DST became permanent. But that would in turn cause problems for parents getting their kids ready for school before they have to go to work. So change working hours? Point being, I can see why some people are in favor of keeping things as they are, as their lives would be considerably more disrupted than mine is having to deal with a clock change twice a year.

      • *or* they could just change when school starts.

        It is literally easier to change time itself than get everybody to change schedules.

  • I'm against DST and all but any programmer that relies on human friendly displayed time (eg 1:30) for storing data for mission critical applications like medical records messed up. The data should be stored with timestamps that are unaffected by things like DST and only convert to more human friendly formats when the data is displayed somewhere.

  • We shouldn't do Daylight Saving Time because.....some hospitals use shitty software written by developers who still can't figure out clock-related bugs after years of trying?

    I honestly don't give a damn whether we change the clocks or not but I do like having usable light at 9 PM, however briefly. I'd rather shift time in the Winter so the sun doesn't go down at 5 PM though. I just need to move much farther South so my winters aren't so cold and dark, and everybody can do whatever the F they want with th
  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Sunday November 04, 2018 @01:03AM (#57588510)
    Comment removed based on user account deletion
    • by Kaenneth ( 82978 )

      How do you expect people to take Global Warming seriously when they think adjusting human made clocks controls how much sunlight there is?

    • I grew up on a dairy farm and the cattle hated the time switch. Not that they'd know why it happened, only that something was up. When milking was an hour late the cows would make all kinds of noise waiting to get into the barn where they knew they could get fed. When it was an hour early it took all kinds of coercion to get them in the barn. We'd open the barn doors and instead of filing in like they normally do they just look at us like we don't belong. It took nearly a week sometimes for the cattle

  • by ukoda ( 537183 ) on Sunday November 04, 2018 @02:13AM (#57588660) Homepage
    Am I the only one who finds it amusing that America can defend the use of Imperial measurements and yet is it daylights savings that is too hard?

    Yea, sorry, mark down as flame bait if you must, but I still find this funny.
    • by mentil ( 1748130 )

      They're one and the same, and boil down to "change is haaaard". As in, a change from a tradition of DST. The government can only succeed in petty sniping and screwing the little guy nowadays, anything that resembles progress was thrown by the wayside. Anything bold that can't be reduced to a soundbite will only happen about once a decade, and even then expect them to screw it up somehow.

  • In 2018 EU decided to end daylight saving time. Or rather let all nation decide for themselves if they want it or not and thus themselves decide which time zone to be in. https://www.bbc.com/news/world... [bbc.com]

  • There's no reason why it needs to be light out at 9:00 on a Summer night.
  • No America is about to COME OFF daylight saving time and return to normal time.

    Although normal time is "correct" dst is more fun to live in (getting home with some light left)

    I see these articles every year here and hatred from Americans about DST when you're infact LEAVING DST right now.

  • There is a very easy way to have avoided these problems with medical records:
    • Internally, all times are kept in a universal, unambiguous format: GMT is suggested
    • It is the responsibility of the input and display programs to convert between internal format and local time.

    I instigated this for environmental models two decades ago, and it makes life lots easier. And more error-free.

    Of course, there are those DB idiots who won't learn from history, and keep trying to reverse that decision... ;-(

1 1 was a race-horse, 2 2 was 1 2. When 1 1 1 1 race, 2 2 1 1 2.

Working...