5 ms·

We had situation where if you worked late, the test suite would consistently fail. Since developers rarely worked late and would give up when hitting the "rand

We had situation where if you worked late, the test suite would consistently fail. Since developers rarely worked late and would give up when hitting the "random" test suite failure and go home, the bug persisted for months before the true cause was understood. Our time zone was UTC-5, and the test suite contained a local-vs-UTC bug which only triggered between 7pm and midnight.

monkpit 5y ago
I feel like this is relatively common (unfortunately)
- Nextgrid 5y ago
  It is. I'm in London which means that our time is +/- 1 hour of UTC depending on daylight saving time. There's been a couple projects where if I pushed a commit between 11pm and 1am some tests would break. I'm pretty sure the issue is inconsistent use of UTC vs local time which during that period will differ by one day.
  - ipsi 5y ago
    One of the perils of working in the UK is _assuming_ that you've been using UTC timestamps this whole time, and then summer rolls around and suddenly a bunch of tests start failing, and all your production logs are an hour out because you were wrong, and actually used local timestamps everywhere. Oops.
cstejerean 5y ago
I had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.
- ihateolives 5y ago
  I worked with date range in a service that expected start date to be inclusive, but end date to be exclusive. So when you wanted to get data from dates 12-15, you'd have to send query for 12-16.
  - tremon 5y ago
    That sounds like a naive date->datetime conversion rather than explicit boundary exclusion. If you convert a date to a datetime, you get midnight at the start of day, which is fine if you're only comparing dates, but fails spectacularly in the way you describe for date ranges. MSSQL not supporting a DATE data type has been the bane of my existence for a long time (of course, Postgresql has supported it since forever, but try telling your application vendor that). And since it took so long to include it, hardly any application uses it even today, because of inertia and compatibility with existing databases.

monkpit 5y ago

I feel like this is relatively common (unfortunately)

Nextgrid 5y ago
It is. I'm in London which means that our time is +/- 1 hour of UTC depending on daylight saving time. There's been a couple projects where if I pushed a commit between 11pm and 1am some tests would break. I'm pretty sure the issue is inconsistent use of UTC vs local time which during that period will differ by one day.
- ipsi 5y ago
  One of the perils of working in the UK is _assuming_ that you've been using UTC timestamps this whole time, and then summer rolls around and suddenly a bunch of tests start failing, and all your production logs are an hour out because you were wrong, and actually used local timestamps everywhere. Oops.

cstejerean 5y ago

I had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.

ihateolives 5y ago
I worked with date range in a service that expected start date to be inclusive, but end date to be exclusive. So when you wanted to get data from dates 12-15, you'd have to send query for 12-16.
- tremon 5y ago
  That sounds like a naive date->datetime conversion rather than explicit boundary exclusion. If you convert a date to a datetime, you get midnight at the start of day, which is fine if you're only comparing dates, but fails spectacularly in the way you describe for date ranges. MSSQL not supporting a DATE data type has been the bane of my existence for a long time (of course, Postgresql has supported it since forever, but try telling your application vendor that). And since it took so long to include it, hardly any application uses it even today, because of inertia and compatibility with existing databases.