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.
"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.
Just sick of this (Score:5, Funny)
The absolute worst part of DST is the stupid semiannual bitchfest on Slashdot.
Re:Just sick of this (Score:4, Insightful)
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)
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
Re: Just sick of this (Score:2, Interesting)
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.
Re: (Score:3)
Suppose a nurse looks at a patient's "chart" at 01:45 after the time switch and sees a medication was given at 01:30. Suppose the patient is allowed to, on request, have the medication not more often than once an hour (and, perhaps, there are additional limitations on the number of doses in a 24 hour period). If the patient asks for another dose at this time, does the nurse say "Sure" or "I'm sorry Mr Senile, you can't have another dose for another 45 minutes. You have probably forgotten, but you had a dose
Re:Just sick of this (Score:4, Insightful)
WTF?
BTW, DST sucks just as bad in Europe.
Re: (Score:3)
For your info, Europe has DST too. At least for now, we're one step further, we're actually trying to get rid of it. Chances are good that this was the last time we had to torture our clocks and our biorhythm.
It's pretty much a given that screwing with the time twice a year is over. What people are divided about is whether to adopt permanent DST or permanent normal time.
Re: (Score:3)
Doesn't matter. We're just not dumb enough to enter ridiculous wars. Anything cheap should do.
UTC people (Score:5, Insightful)
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.
Re: UTC people (Score:2)
Re: UTC people (Score:5, Insightful)
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."
Re: (Score:2)
China and India don't use DST.
Re: UTC people (Score:5, Informative)
Re: (Score:2)
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
Re: (Score:2)
I'm one of those who do care. I share your disgust of those who don't. It's not necessary or helpful.
Re: UTC people (Score:2)
Re: (Score:2)
All of those points are valid. I'd probably add that coding standards are for pretty printing, not software integrity, in many places.
Education is a core problem, since you can't get bad managers if they are well-educated. Health is another core problem. On these two pillars, almost all else rests, which is why I've burned many brain cycles trying to figure them out.
1-4 are a lack of proper specification and an assumption that you can design on the fly. I can, but I hate it.
6-7, 9 are why I abandoned Americ
Re: (Score:2)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
UTC represented as an epoch number (Score:4, Insightful)
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.
Re: (Score:2)
I once had to help someone over the phone with troubleshooting a database system that wasn't handling dates correctly; they were cataloging tombstones.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
Using a signed 64-bit type.
Re: (Score:2)
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'
Calendar time is for calendars (Score:3)
I agree there is a reason it's called calendar time.
Because it's what people use for calendars.
That's its appropriate use. If we set an appointment for 9:00 AM November 1, 2023, we mean when the clock reads those values - whatever time that happens to be. We don't yet know what time that will actually be (how many seconds away it is) because we don't know whether DST will be in effect.
You're slightly mistaken about epoch time and leap seconds.
Epoch time is how long it has been since the epoch. Epoch time d
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
UTC = Win, but it's complicated (Score:2)
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.
Re: UTC people (Score:2)
Fun fact: it uses 1840 as the epoch because when MUMPS was written that was the birth year of the oldest person currently living.
That kind of makes sense, given that it was written to handle patient records at MGH: you're guaranteed to never take in a patient older than that, and the original system was simplistic enough that it wouldn't need to handle complicated dates.
Google Anyway.... (Score:2)
Re: (Score:2, Funny)
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.
Re: (Score:2)
Here's some fun (Score:2)
Give someone some LSD tonight and then change the clocks.
Re:Here's some fun (Score:5, Funny)
Give someone some LSD tonight and then change the clocks.
I do that every weekend, what makes this weekend any different?
Re: (Score:2)
Give someone some LSD tonight and then change the clocks.
I do that every weekend, what makes this weekend any different?
When you're done the clocks may be right.
I for ohe am happy (Score:3)
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,
Any software... (Score:2)
That can't properly handle the unfortunate, antiquated reality of daylight savings time is written by idiots. The same goes for leap time.
Re: (Score:2)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
I'm of two minds here;
With a system that keeps getting vendor updates, I do believe that /var/lib/leapseconds would be the right place.
However, given the plethora of very old systems around, I do believe it should be in a human configurable file. I would find it quite unnatural for sysadmins to go and inject leapseconds into a file in /var/lib. Echoing the "leapsecond timestamp" into /etc/leapseconds would, however, be entirely natural.
I can live with both, though - we're currently simply bikeshedding ;-)
Re: (Score:2)
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.
Re: (Score:2)
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.
Keep it on daylight saving forever please. (Score:5, Insightful)
I love the later sunsets at the evenings. ;)
Re: (Score:2)
Yeah, I’d prefer permanent Daylight Saving over permanent standard time.
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
I solved the problem by finding a job that's not sensitive to me being an hour late during the ridiculous times in Summer.
Re: (Score:2)
The reason is that even in winter, it gives people more waking daylight hours than Standard Time does.
Re: (Score:2)
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
Re: (Score:2)
And the later sunrises in the morning in Winter? How much do you like to drive to work in pitch black darkness?
Re:Keep it on daylight saving forever please. (Score:4, Insightful)
OK, so you get up an hour early, go to work an hour early, and find the door locked. Then you finally get in, get ready to leave an hour early, and for some reason the PHB objects, so POOF, there goes your sunset, you'll be driving home well into twilight.
Re: (Score:2)
Early bird is now linked with health problems and shortened lives. Just as with smoking in the 1700s, being accepted doesn't equate to being smart.
As far as I know (Score:3)
In fact, it is not complicated, - a government makes a decision and publishes it. This is it, the sanity is back.
Re: As far as I know (Score:5, Insightful)
Re: (Score:2)
Fuck it, I'd vote to re-elect Trump if he abolished DST.
Re: (Score:2)
I guess that means it doesn't matter to most of the people and those that do care want to get rid of the bullshit.
"Literally everyone hates it... " (Score:2, Troll)
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
Re:"Literally everyone hates it... " (Score:4, Insightful)
*or* they could just change when school starts.
Re: (Score:2)
*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.
Re: (Score:2)
*or* they could just change when school starts.
It is literally easier to change time itself than get everybody to change schedules.
Timestamps (Score:2)
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.
Re: (Score:2)
You really have to reach sub-microsecond for anyone to notice. These days, you have to get to nanosecond accuracy before the complexity starts to show, and that's only because the timestamps can be funky at that level.
Bad reasoning (Score:2)
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)
Re: (Score:2)
How do you expect people to take Global Warming seriously when they think adjusting human made clocks controls how much sunlight there is?
Re: (Score:2)
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
Is it really that difficult? (Score:5, Funny)
Yea, sorry, mark down as flame bait if you must, but I still find this funny.
Re: (Score:3)
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.
EU has abondoned daylight saving time (Score:2)
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]
Daylight Wasting Time Must End (Score:2)
Here we go again,...... (Score:2)
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.
Re:Here we go again,...... (Score:4, Interesting)
Yeah, see, it's such a bad idea that even a /. headline doesn't get it right.
Also, go work for a company that starts work 1 hour sooner in the summertime. Somehow, Home Depot manages to change their hours twice a year, unrelated to the government calendar, and everybody gets by just fine.
Medical records and STUPID systems architects (Score:2)
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... ;-(
Re: this again... (Score:4, Insightful)
And every year we have the vociferous few who will defend their supposed god given right to force everyone into being a nation of clock fiddlers.
Sadly, almost every year about a couple of weeks before DST ends there is some news story about kids being killed walking to school in the dark - because the car driver could not see them on the dark road.
I am quite sure that there are hundreds of people who have died as a result of supposed daylight savings time. This story mentions just one of the problems that could lead to delays with acessing much needed medical records in a timely manner.
Imagine if there would need to be an airline full of people that would be rammed into the ground when the law was written so we all could be forced to fiddle with our clocks. Do you think that the law instituting it would pass then?? Because we've probably lost more lives than that to the ignoble DST since it was passed back in the '70s. It's time to stop listening to the loudmouths and stop
having to put up with their forced stupidity.
Re: (Score:3)
I am sure that you are correct that lives are lost from the switching back and forth. I do think that it is kind of stupid adjusting the time twice an year.
But, as someone who enjoys the time after work more than the time before work, I far prefer being on Daylight Saving Time. So, as far as I am concerned, we should just do away with high noon at 12pm. I am perfectly fine with the Sun's zenith being at 1:30pm, as it is during the Summer where I live.
Re: (Score:2)
Why don't you just leave the clocks alone and work 8-4 instead of 9-5 then? (And please don't reply that that means getting up an hour earlier, because that's precisely the kind of irrational BS that keeps DST alive).
Re: (Score:2)
This story mentions just one of the problems that could lead to delays with acessing much needed medical records in a timely manner.
That's caused by sloppy programming.
Re:this again... (Score:5, Informative)
All the same problems happen if you change timezones when you move.
Um, no. When you move, you're in a different place. I know that's a challenging notion for someone who lives in Mom's basement, but please do try.
When we we go off DST here, you go from sunset at 5PM one day to sunset at 4PM the next. It is quite unsettling.
Re: (Score:3)
Re: (Score:2)
Exception proving the rule? [epicrecords.com]
Re: (Score:2)
Another to add to the list
https://en.wikipedia.org/wiki/... [wikipedia.org]
Han Solo in carbonite (Score:5, Funny)
The "word on the street" is that Epic Systems has a high level of employee turnover, in part because of burnout of the persons involved, in part because the company's approach to firing people being that of the Queen of Hearts from Alice in Wonderland ("Off with his head!").
I have been told by people who have been out to their Verona, WI campus that there is a wall, where employees reaching their 2-year employment anniversary record their hand prints in plaster. I guess a 2 year anniversary is a big milestone if you work there.
My question is, are those hand prints on the outside pushing in, or are do they appear from the inside of the wall pushing out?
Re: (Score:2)
No, the fall change is worse—at my latitude, this makes it start getting dark in the middle of the freaking afternoon, due to sunset suddenly being one clock hour earlier.
Re: (Score:2)
Just make every day 9.85 seconds shorter, so we can get that hour 'rebate' every spring still.
Re: (Score:2)
every fall I mean =P
Re: (Score:2)
Why should they? Where's the profit motive? They're on lowest bid, they're paying the code monkeys in peanuts, there's no meaningful penalty for getting it wrong - only for getting it late.
Patients can't use the vendors and hospitals have no incentive. It only kills a few people each year, far fewer than the synthetic opium they hand out.
Re: (Score:2)
Why? UTC does not change.
Re: (Score:2)
As DST isn't typically observed in the winter, I'm wondering how you figure DST contributes to that particular winter phenomenon.