6 ms·
A couple of years ago, I did work for a major airline where the test suites that would test date processing would fail on every leap year (Feb 29). So they dec
by game_the0ry 5y ago
A couple of years ago, I did work for a major airline where the test suites that would test date processing would fail on every leap year (Feb 29). So they decided not to run tests or deploy on Feb 29th.
- jlkuester7 5y agoLol, reminds me of of the large EMR platform I used to work on that (until very recently) could not handle the "fall back" DST event (thanks to local date encoding in very parts of the system).... So the recommended 'fix' for hospitals was to just turn it off (their entire electronic health record) for the duration of the DST changeover... I personally believe that a non-trivial amount of people die due to DST and similar time related bugs...
- mark-r 5y agoDST has long overstayed its usefulness. I wonder why it's so hard to get rid of?
- curiousllama 5y agoOh, EMR systems kill patients all the time. Like, I’m not convinced “turn it off” isn’t an improvement.
- mr_toad 5y agoPoor record keeping practices in general have been linked to killing patients. Especially ones involving medication errors. It’s not like paper systems were perfect or even demonstrably better.
- game_the0ry 5y agoI hesitate to find it amusing that healthcare software is so busted that we laugh off the negative, fatal consequences.
- tata71 5y agoNo, the commenter isn't laughing or joking. They're that bad.
- thfuran 5y agoNot having one at all is also bad.
- throwawayboise 5y agoHow so? "First, do no harm" is the foundation of medicine.
- wereHamster 5y agoNot of software engineering though.
- dragonwriter 5y ago> How so? Empirically, it's associated with a higher rate of medical errors, which is a big part of the drive for electronic records.
- patmorgan23 5y agoPaper medical records systems cause errors/deaths for several similar reasons that electronic medical record systems. EMR's with all their faults are probably a net positive.
- alisonkisk 5y ago
- riahi 5y agoFrom personal experience, this is Epic.
- belter 5y agoFor anybody who missed this very insightful comment :-) see the "Criticisms and controversies" section: https://en.wikipedia.org/wiki/Epic_Systems#Product_and_market https://en.wikipedia.org/wiki/Epic_Systems#Product_and_marke...
- tuukkah 5y agoYes. Epic was deployed in Helsinki in 2021, and you bet it miscalculates the administration of recurring medications during DST changes, which nurses then need to correct manually.
- tharkun__ 5y agoSame for SAP. Seems like it's still 'best practice' to do so: http://www.sapbasis1solution.com/how-to-prepare-sap-system-for-daylight-saving-time-change/ http://www.sapbasis1solution.com/how-to-prepare-sap-system-f... During this time of one hour “Fall Back” on the clock, as is our Basis team best practice (SAP Note #7417, #102088 and others) we intend to gracefully shut down all Production applications prior to 2:00 AM, at which time the “fall back” happens that will revert back clock time by one hour. We would then wait for clock time to advance past the “new” 2:00 AM Local time. And start from 2:05 AM EST will bring up applications.
- Hamuko 5y agoOur unit tests break twice a year, starting a couple of days before DST change. I'm sure it could be solved, but since the DST change happens on Sunday and the CI builds fail on Friday, no one has really bothered.
- Dunedan 5y agoSo I guess your units tests run with the current date and don't test behavior with different dates. That's something which has the potential to hide quite a few date related bugs until it's too late. What I like to do to avoid this situation is to use property-based testing to test that the code works for all dates in the desired time span. For Python I use hypothesis [1] in combination with freezegun [2] for that. Here is an example of how that could look like: from datetime import datetime, timezone as tz from freezegun import freeze_time from hypothesis import given, strategies as st def business_logic(): # TODO: Refactor before 2038! if datetime.now(tz=tz.utc) > datetime(2038, 1, 19, 3, 14, 7, tzinfo=tz.utc): raise Exception("This code is not working after UNIX time overflow") ... @given(dt=st.datetimes(max_value=datetime(9999, 12, 31, 23, 59, 59), timezones=st.just(tz.utc))) def test_business_logic(dt): with freeze_time(dt): business_logic() test_business_logic() [1]: https://hypothesis.readthedocs.io/en/latest/ https://hypothesis.readthedocs.io/en/latest/ [2]: https://github.com/spulec/freezegun https://github.com/spulec/freezegun
- Hamuko 5y agoIt's just that the unit tests are built on the assumption that if you go forwards 24/48/72 hours, the time will be the same but N day(s) ahead. And that breaks down when you shift time zones. >don't test behavior with different dates It basically tests with different dates every time it's run.
- denton-scratch 5y ago> the CI builds fail on Friday That seems different from what I understand by "continuous integration".
- 5y ago
- mdavidn 5y agoOne project had tests fail every Saturday and Sunday, near the organization’s fiscal week boundary. Ever since then, I have strived to hard-code all dates in test suites, choosing dates several decades in the future.
- alisonkisk 5y agoDoesn't that just hide the bugs? Your tests should pass on any and all date.
- mdavidn 5y agoNo. I write explicit tests on the boundaries, such that they would fail on any day of the week.
- rbanffy 5y agoThe outcome of tests shouldn’t depend on the time of day. Are these integration tests and you are having to deal with external bugs you can’t fix?
- treeman79 5y agoWe doing a midnight deploy with 40 people. After boss explained process. I asked him, so are we deploying on the first midnight or the second? Long quiet pause, then a series of curses. So we deployed at 2am instead.