5 ms·

This, and many incidents like it, makes me think that running tests 1/10/100 years in the future should be a standard feature of test runners and CI systems. (o

• sdrothrock 9y ago
  I work with time a lot and have always advocated running practical simulations, especially over year changes, leap year changes, leap year days, etc. with the junior engineer I mentor as well as the hardware company that partners with us -- it's only recently after we got bitten by a time-based bug that people have started listening.
  • taberiand 9y ago
    Of course, if they had listened and therefore never been bitten, they would have seen the work as a waste of time.
    • sdrothrock 9y ago
      That's the nature of the beast. I have to be the noisy guy about testing and also be the guy who doesn't say "I told you so," but instead continues pushing testing.
    • Sylos 9y ago
      I mean, they would have noticed when a test actually runs into a problem, but yeah, it's not nearly as visible as something actually going wrong in production.
• toomanybeersies 9y ago
  I had a bunch of tests fail at the start of this year because someone had hard coded 2017 into the tests. Fortunately it was a problem with the tests, rather than the code itself, but these things do happen. At my old job, we had a bunch of tests fail when daylight saving ticked over. For some reason, some things were using local time, rather than UTC. We also had a test that would fail if the minute was the same as the hour. Time is hard
• olliej 9y ago
  The kicker of course is that if you set the date to something in the future you may have a pile of other services fail before your code is run — Basically any /other/ services that happen over TLS may fail (correctly as their certs have expired ;) ).