4 ms·

Pro tip: add test cases to your CI runs with modified system date.

WesolyKubeczek 5y ago
The thing is, you need to have a pretty corkscrew mind to think about cases like this. What date to change to? Far into the future? Far into the past? To a weekend? To a DST change? To Friday the 13th? To a US holiday? To a Muslim, Jewish, Chinese, Soviet, Albanian holiday? To a particular weekday? To Hitler's birthday? What if it's Lenin's? To that one day my coworker was depressed because the boss denied him a raise and talked shit to him? Too many possibilities. And your timebomb might be in one of your dependencies to boot.
- zanderwohl 5y ago
  I feel obligated to link "Falsehoods programmers believe about time" - I think it's best to just get a trusty library instead. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
JohnBooty 5y ago
Amen. Worked for a few years at a company with a medium-sized codebase whose tests only worked before 6PM. (Run the tests later than that, and you wind up with some timeframes that span calendar days and therefore break things. Was the underlying code broken, or the tests, or both? Who knows!!) Was never allowed to fix and investigate. Or to be specific, we were never given the time to fix it. Management simply didn't see it as a problem. In my younger days I would have gone all HERO HACKER and fixed it anyway on my own time. But now, I know how that turns out. You waste a bunch of evenings fixing it, and usually introduce some other regressions, and you get zero glory and lots of blame. Best case scenario is no regressions and zero glory. So, screw it. Old-and-jaded me never lifted a finger. If the company doesn't care, why should I? But, that is an excellent protip. If you are working on a team that actually values things that work. Time/date dependent code is very tricky to get right, especially when multiple time zones are involved. If your test suite doesn't cover multiple possibilities, your code is nearly guaranteed to be wrong. It's not even like you have to write brand-new, cleverer tests. Just "brute-force" it, assuming your tests are performant: before: some_tests after: [time_zone_1, time_zone_2, time_zone_3].each do |tz| [time_of_day1, time_of_day2, time_of_day3].each do |tod| some_tests(tz, tod) end end ...that kind of thing. That's what I did when I wrote new code at that company, even though I refused to fix the legacy stuff. My tests were faster, too. Almost like I knew what I was doing...
- janekm 5y ago
  Was it a German company? If so "you can only do work during working hours" would be considered a feature not a bug ;)

The thing is, you need to have a pretty corkscrew mind to think about cases like this. What date to change to? Far into the future? Far into the past? To a weekend? To a DST change? To Friday the 13th? To a US holiday? To a Muslim, Jewish, Chinese, Soviet, Albanian holiday? To a particular weekday? To Hitler's birthday? What if it's Lenin's? To that one day my coworker was depressed because the boss denied him a raise and talked shit to him? Too many possibilities. And your timebomb might be in one of your dependencies to boot.

zanderwohl 5y ago
I feel obligated to link "Falsehoods programmers believe about time" - I think it's best to just get a trusty library instead. https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

JohnBooty 5y ago

Amen. Worked for a few years at a company with a medium-sized codebase whose tests only worked before 6PM. (Run the tests later than that, and you wind up with some timeframes that span calendar days and therefore break things. Was the underlying code broken, or the tests, or both? Who knows!!) Was never allowed to fix and investigate. Or to be specific, we were never given the time to fix it. Management simply didn't see it as a problem. In my younger days I would have gone all HERO HACKER and fixed it anyway on my own time. But now, I know how that turns out. You waste a bunch of evenings fixing it, and usually introduce some other regressions, and you get zero glory and lots of blame. Best case scenario is no regressions and zero glory. So, screw it. Old-and-jaded me never lifted a finger. If the company doesn't care, why should I? But, that is an excellent protip. If you are working on a team that actually values things that work. Time/date dependent code is very tricky to get right, especially when multiple time zones are involved. If your test suite doesn't cover multiple possibilities, your code is nearly guaranteed to be wrong. It's not even like you have to write brand-new, cleverer tests. Just "brute-force" it, assuming your tests are performant: before: some_tests after: [time_zone_1, time_zone_2, time_zone_3].each do |tz| [time_of_day1, time_of_day2, time_of_day3].each do |tod| some_tests(tz, tod) end end ...that kind of thing. That's what I did when I wrote new code at that company, even though I refused to fix the legacy stuff. My tests were faster, too. Almost like I knew what I was doing...

janekm 5y ago
Was it a German company? If so "you can only do work during working hours" would be considered a feature not a bug ;)