Hacker News Reader

Comment by walnutclosefarm | Hacker News Reader

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

View on HN

That's a good point... things like "every 4 hours" gets complicated around the time change if you need things to align with a clock

Not necessarily, just track elapsed time and ignore absolute measures.

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

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

The 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)

The "almost" makes it sound trivial but hides complexity, e.g. around leap seconds.

https://en.wikipedia.org/wiki/Leap_second

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

> At the risk of being pedantic. No, these are not the same.

Absolutely agree and that was my point in the comment you replied to.

If you want to measure elapsed time you should not involve absolute time measures because then you will not need to think about leap seconds or DST changes.

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

And what sort of instrument might you use to track elapsed time?

Measuring 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

In rust you use https://doc.rust-lang.org/std/time/struct.Instant.html

A computer? Like the stopwatch app on your phone does. (I think I'm missing your point)

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

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

The main complaint I've heard about EMR in the US is that it massively increased the bookkeeping overhead that staff had to deal with. Particularly since it tends to fall in the realm of "terrible enterprise software no one asked the users for opinions on."

Some kind of punch clock system for every action would make that even more tedious, I imagine.

Such 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).

Coincidentally, misinterpretations or loss of these free form notes is a major source of problems in hospitals.

To 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-nt...

To err is human, but the solution in that case is to replace human judgment with technology

> Federal officials subsequently issued new rules for nighttime landings and control-tower staffing. Now, when an adjacent runway is shut down at night, air traffic controllers will no longer let pilots make so-called visual approaches to land. Instead, they must use instrument landing systems or satellite-based systems to line up for the correct runway.

Not sure this supports that "unambiguous language" is the problem. To me it sounds like the problem is "humans being expected to perfectly perform routine tasks" - and the solution is to move as much of the task away from the humans as possible. I imagine there are parallels in the medical system (but am not expert).

The big problem with that is you don't know if someone has done the time adjustment. Eg you know there's a handyman who does this twice a year, perhaps he's done it before the 2am official cutover time because his shift ended earlier? Or he'll do it the next morning?

Similarly it's not obvious whether your phone keeps an eye on this for you, if you're not a techie type. And if you are, how do you know what your elapsed time stopwatch does under the hood?

One of my cars gets time from the radio, the other one doesn't, so around this time of year they show different times.

Stopwatch.

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

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

Cerner millennium can't handle it well

And in the spring us devs can end up with NonexistentTimeErrors.

Reply on news.ycombinator.com