5 ms·
> I am in favor of permanent standard time, but failing that, I am super happy with permanent daylight-saving time. Ditto. Switching is the issue for me. A
by walnutclosefarm 5y ago
> I am in favor of permanent standard time, but failing that, I am super happy with permanent daylight-saving time.
Ditto. Switching is the issue for me. And it's not because it's all that disruptive to me personally. But it is highly disruptive, and dangerous to shift workers. The fall change in particularly raised hell in the hospital where I worked, since it literally created an hour that occurred twice. Computers can store time in universal time, but a nurse medicates or does a procedure on a patient by clock time, and that duplicate hour and compressed shift increased risk of patient harm, misrecording of data, and overall stress a lot.
And really, it's just dumb.
- giantg2 5y agoAnd in the spring us devs can end up with NonexistentTimeErrors.
- FateOfNations 5y agoThat's a good point... things like "every 4 hours" gets complicated around the time change if you need things to align with a clock
- alophawen 5y agoNot necessarily, just track elapsed time and ignore absolute measures.
- sirmarksalot 5y agoAnd what sort of instrument might you use to track elapsed time?
- gpm 5y agoA computer? Like the stopwatch app on your phone does. (I think I'm missing your point)
- cornstalks 5y agoI think the parent's point was that most medical staff (in my experience) use normal wall clocks to track time. I've never seen a per-patient stopwatch.
- gpm 5y agoI guess I'm naively assuming that there is some sort of patient management software which keeps track of what needs to happen when for whom, to enable things like shift changes without losing information. But I definitely don't have any idea how this part of the medical world actually functions.
- sangnoir 5y agoSuch a system would be extremely disruptive to nursing staff- it may work well with robots though. Most hospitals track care on patients chart, which is computerized, but boils down to free-form text[1] that relies on humans interpreting,executing and updating the chart. 1. Patient care is very bespoke, with all manner of combinations for treatments, including contra-indicated medications. It's similar to why it's hard to automate air traffic control (lot's of human factors at play that require human decision making).
- adrianN 5y agoCoincidentally, misinterpretations or loss of these free form notes is a major source of problems in hospitals.
- sangnoir 5y agoTo err is human. Until we develop a language that is perfectly unambiguous,all we can do for now is minimize chances of miscommunication. To continue on the air traffic comparison, sometimes the pilots land on the taxiway[1] despite clear instructions 1. https://www.cbc.ca/news/business/air-canada-investigation-ntsb-1.4646179 https://www.cbc.ca/news/business/air-canada-investigation-nt...
- girvo 5y agoStopwatch.
- deleted 5y ago[deleted]
- alophawen 5y agoMeasuring elapsed time in golang is as easy as: start := time.Now() // Code to measure duration := time.Since(start) See the docs for a good write-up: https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks In rust you use https://doc.rust-lang.org/std/time/struct.Instant.html https://doc.rust-lang.org/std/time/struct.Instant.html
- deleted 5y ago[deleted]
- elromulous 5y agoAt the risk of being pedantic. No, these are not the same. And tracking elapsed is actually harder. Consider coding these two solutions (for n "patients"), in one you simply keep a timestamp of each and check against current time. In the other, you have many timers / stopwatches in parallel. The simplicity of simply recording the time and checking it against current time absolutely extends to the physical world.
- elromulous 5y agops yes, you can implement n timers using a single underlying timer, but that of course requires even more book keeping, which was the point of my comment in the first place.
- shhsshs 5y agoThe two problems are almost exactly the same if you just use a time frame that does not change (permanent daylight savings, or never daylight savings)
- aix1 5y agoThe "almost" makes it sound trivial but hides complexity, e.g. around leap seconds. https://en.wikipedia.org/wiki/Leap_second https://en.wikipedia.org/wiki/Leap_second
- walnutclosefarm 5y agoLeap seconds are a problem too, but in entirely different settings, and in a way that is much better encapsulated in the software engineering world. I personally think the world would be better off without them, and that we should just let the clock/calendar drift back and forth, and in the long term off, true midnight. Outside of navigation and astronomy and a few other highly specialized fields, this has no meaningful impact, and would vastly simplify automated time recording. But it's a decision that has to be made globally, not nationally or locally, and requires a LOT of coordination to get right. It is also fundamentally different in nature, in that leap seconds never create duplicate times in the time sequence. Leap seconds are changes to the sequence of the underlying elapsed time sequence; DST changes are not, but only change the representation and use of time values.
- walnutclosefarm 5y agoI have heard this argument from software developers over and over again - not one of whom has ever actually worked through a shift in an ICU or critical care, or med-surg ward. I doubt if any of them have ever worked ANY shift work that spanned a clock change. The problem is not in the representation of time values in the system, it is in the system-human interface, and the actual work in the hospital that is tied to wall clock time. 2:30AM means something to these workers and patients, and having a shift or day when there are two 2:30AMs, or no 2:30AM f**s things up. That the software is poorly designed to support the change exacerbates the problem, but isn't the actual cause of it.
- organsnyder 5y agoAt a healthcare system I worked at, the EMR would be shut off for the repeated hour in the fall. I'm not sure if it was because the EMR couldn't handle it (very possible, since all EMRs are shitty) or if it was the human factor that was the problem.
- IThoughtYouGNU 5y agoCerner millennium can't handle it well
- walnutclosefarm 5y agoNone of the major Electronic Medical Records system handled the time switch gracefully, and the solution you describe was standard practice with both Cerner and Epic for many years. When we installed Epic at the academic medical center where I worked, we insisted on significant changes and upgrades so that a shutdown would not be necessary. Epic is pretty solid now. But the system can't solve the core problem - taking an hour out, or adding a duplicate one in, is highly disruptive to nurses already very busy schedules, and introduces multiple sources of potential confusion in patient care.