3 ms·

A fun one that I came across was a test (in an old rails app I was maintaining) that failed only on the 29th January in years preceding leap year. The test was

by SEMW 11y ago

A fun one that I came across was a test (in an old rails app I was maintaining) that failed only on the 29th January in years preceding leap year. The test was: Subscription.new (starts_at: 1.month.from_now).ends_at.should == 13.months.from_now On 29th Jan 2015, 13.months.from_now is 29th Feb 2016; but 1.month.from_now = 28th Feb, plus a year gives 28th Feb 2016. (Possible conclusion: when using activesupport-style magic date helpers, look up their exact semantics and be sure that what they're doing is what you mean them to do...)

markburns 11y ago
Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problems.
- lmm 11y ago
  If you have time bugs that only manifest at the DST changeover then everyone knows why your bugs have happened and you look incompetent. I suspect this applies if subscriptions handle leap years poorly too.
  - markburns 11y ago
    My point is more that if it costs more to fix it now, than it does to fix it later (including the opportunity cost), then there is little point in fixing an extreme edge case now. Especially if it means having to understand every intricacy of every library you work with and spend a long time thinking of permutations that have little effect on the business. It depends on the situation you are in as to whether that cost calculation works out in your favour. It is not always that is has to always work in 100% of edge cases, all thought about up-front and with no possible bugs arising due to not 100% understanding every line of code in every library. Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. In this case the bug may manifest itself in a user potentially seeing a day off by one error on a subscription details page. In which case it may never make sense to fix that page. As the user may never look at that page, and even if they did, they may never care.
    - lmm 11y ago
      > Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. Sometimes yes, but you need to actually perform the risk assessment/cost-benefit analysis. Many bugs are costly enough that it's worth fixing them pre-emptively rather than always waiting for a problem to happen before you do anything about it.

by SEMW 11y ago

markburns 11y ago

Another possible conclusion: fix this several years from now, the first time it causes a test failure and still probably before it causes any production problems.

lmm 11y ago
If you have time bugs that only manifest at the DST changeover then everyone knows why your bugs have happened and you look incompetent. I suspect this applies if subscriptions handle leap years poorly too.
- markburns 11y ago
  My point is more that if it costs more to fix it now, than it does to fix it later (including the opportunity cost), then there is little point in fixing an extreme edge case now. Especially if it means having to understand every intricacy of every library you work with and spend a long time thinking of permutations that have little effect on the business. It depends on the situation you are in as to whether that cost calculation works out in your favour. It is not always that is has to always work in 100% of edge cases, all thought about up-front and with no possible bugs arising due to not 100% understanding every line of code in every library. Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. In this case the bug may manifest itself in a user potentially seeing a day off by one error on a subscription details page. In which case it may never make sense to fix that page. As the user may never look at that page, and even if they did, they may never care.
  - lmm 11y ago
    > Sometimes it makes more sense to fix a bug that happens every four years when it causes a problem. Sometimes yes, but you need to actually perform the risk assessment/cost-benefit analysis. Many bugs are costly enough that it's worth fixing them pre-emptively rather than always waiting for a problem to happen before you do anything about it.