9 ms·
I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch. Unfortunately, the intern only wor
by johnnyo 5y ago
I had an intern once who wrote similar code. They confused 12 hour and 24 hour clocks, so the code would break after lunch.
Unfortunately, the intern only worked the mornings, so it took several days of back and forth before the bug could be finally put to rest.
- anned20 5y agoIf you tried, you couldn't even come up with this.
- RandalSchwartz 5y agoI could. :)
- alisonatwork 5y agoFantastic. We had a similar problem with test code that always worked on a remote team's computers during their work day but failed when we got into the office and tried to run it in a different timezone.
- allenu 5y agoI've seen something similar where some automated unit tests always passed and when I tried to run it locally would always fail. After digging around I realized it was making assumptions about the timezone it ran in, which was on the east coast, whereas I was on the west.
- pc86 5y agoReminds me of an app I worked on a while ago where both the server it was running on and the datetimes in the database had to be in a specific time zone. Change either (including changing both to an identical but different TZ) and the app just failed to run.
- vidarh 5y agoI've had to fix any number of test suite bugs as well as regressions that happened because the people who wrote the tests had ensured the test suite didn't (most of the time) test what they thought it would by relying on date arithmetic from current date and time...
- salawat 5y agoMany people think that test suite authoring is easy mode. It really isn't. Making a good test suite that actually does a good job of tracking invariants is a royal pain.
- ljm 5y agoAs far as I'm concerned, writing tests is a different skillset and its often underdeveloped. It then snowballs into hating testing, because all you've experienced is a poor test suite that gets worse over time. It's hard to do well as you say, and it also gets glossed over in code review as long as the tests pass. Do the tests actually verify anything useful? Who knows, build is green! That's how you get an application with 50,000 unit and integration tests that you can't run locally, and requires massive parallelism in CI to finish in any reasonable timeframe.
- jamesfinlayson 5y agoMy favourite is the test suite where each test relies on data from every other test, so running a test in isolation fails, and adding a new test is almost impossible without breaking a bunch of other tests.
- salawat 5y agoUgh. Cross test dependency. Mine is lack of future-proofing. Using dates stuck at one point in time. Or worse, the test suite that fails because of local clock skew.
- manojlds 5y agoThat's standard runtime issue right? This is syntax error at compile time.
- dhosek 5y agoKind of sort of. The catch here is that because runtime is compile time with Perl, it's not exactly the same. Looking at the code, it's kind of like having something like #if (some C preprocessor expression that's true on Fridays printf("Hello world!); #else printf; #fi (although it's been long enough since I've written C that I don't know if (a) there exists a C-preprocessor instruction as per the above, (2) if the compiler will notice errors in the unexecuted branch of an #if and (iii) if printf; would give a syntax error). Another equivalent piece of code could be something along the lines of the JS if (today_is_friday()) { eval("2+2") } else { eval("--2abc") }
- garaetjjte 5y ago>(a) there exists a C-preprocessor instruction as per the above There's no day-of-week but you could cause mayhem with __DATE__ >(2) if the compiler will notice errors in the unexecuted branch of an #if Compiler only gets to see preprocessor output, it won't. >if printf; would give a syntax error Perhaps surprisingly but no, it's just statement without effect (containing expression returning function pointer to printf).
- nousermane 5y ago> you could cause mayhem with __DATE__ It takes some patience, but people do try: https://stackoverflow.com/questions/11697820#16472369 https://stackoverflow.com/questions/11697820#16472369
- deleted 5y ago[deleted]
- ihateolives 5y agoI once had to implement date picker that returned the date to be sent to backend to fetch the day's reservations. It seemed to work fine the day I implemented it. Next day it broke. Turned out the widget returned MM/DD/YYYY instead of DD/MM/YYYY. And I implemented it on 10th of October.
- PixelOfDeath 5y agoAliens landed on this planet, found out about the date format MM/DD/YYYY, and left in a hurry. They are currently preparing a gamma ray burst out of pure compassion and pity but also a hint of disgust!
- Ma8ee 5y agoIs that date format used anywhere outside the US? We have always used YYYY-MM-DD. Which is very nice, if for nothing you can use a single string sort if for whatever reason need to sort them.
- adhoc_slime 5y agoI've learned the hard way that this is also dependent on the user's date format set on their computer in some libraries(iirc it was jquery ui date picker a few years back). its liberating when you decide to throw it all out and just use integers for all things not facing an end user.
- mark-r 5y agoI'm a big fan of ISO 8601. Eliminates the confusion, and sorts lexicographically too.
- knodi123 5y agoHa. I had an intern who wrote code that blew up if the timestamp of our DB server was ever >= 1 second after the timestamp of our app server. It couldn't fail at his desk, because he ran both servers locally while developing. And it wouldn't fail in production in the morning, since we had a cron job that synced the clocks at midnight. It took until after 5pm for the clocks to drift enough, meaning I was on call and the intern was not. But the bug didn't crop up until his code had been in production for a couple of weeks, so it was a real pain in the neck to track down.
- barbs 5y agoI'm surprised that got through code review
- knodi123 5y agoThis was the early 2000s, at a very small startup funded privately by a non-technical guy, and most of the technical staff was under 25. It's a big world, and best practices are not universal.
- bentcorner 5y agoPersonally I really don't like code that deals with time - it's too easy to place a "get time stamp" call anywhere in code. If it's down in the bowels of some piece of functionality trying to test it becomes a headache.
- sandinmyjoints 5y agoThis is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.
- 5y ago
- markstos 5y agoWe 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 agoI feel like this is relatively common (unfortunately)
- Nextgrid 5y agoIt 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 agoOne 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 agoI had to fix tests that broke from 11pm-midnight because some assumptions that now() + 1 hour was the same local date.
- ihateolives 5y agoI 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.
- lanstin 5y agoI had a coworker working on a data-pipeline sort of thing once. They for some reason wrote their own date parser (Akamai logs) and used a regular expression to find the month. For whatever reason, the RegExp didn't work for March (I think) and so at midnight 1 March the year of first deploy, we started dropping all the logs as un-parseable (causing the NOC to think the traffic had gone to 0 or our system was buggy). We all got paged and eventually figured out it. It had been running in live for several months without problems at that time.
- usrusr 5y agoFortunately we rarely use 12h clocks where I live. But that opens up other avenues: if you are not much of an early riser, a build script failing to deal with single digit hours can remain undetected for a very long time.
- actually_a_dog 5y agoIt could have been much worse. At least you didn't have a leap year or timezone bug. I've exterminated more than one of those in my time as an engineer, and it's never really any fun.
- deleted 5y ago[deleted]
- wumpus 5y agoOne perhaps apocryphal story that's kicking around out there was that Draper Labs had a hard-real-time navigation system which... took too much time computing something when the moon was full.
- nitwit005 5y agoSaw some tests that had the same pattern. Passed half the day, and failed the other half of the day. I assume it always worked during India work hours.
- divbzero 5y agoLike many here, I’ve faced similar challenges in debugging time-dependent code. What is the best way to set or mock system time during testing?
- stmuk 5y agoI once took over code which only worked in single digit month numbers.