5 ms·
I got two I noticed over the years: * Didn't think about time at all. In most cases most don't think about time until it becomes a problem. It often ends up w
by rdtsc 10y ago
I got two I noticed over the years:
* Didn't think about time at all.
In most cases most don't think about time until it becomes a problem. It often ends up with a system which behaves in surprising ways, and is the equivalent to the developer believing any of those things in the article. But there is a difference in them believing those falsehoods, and simply not being a aware of them at all.
* Time moves forward
This is probably the biggest gotcha of all. Just imagine how many times int the past you did dt = now() - t0, then did something with dt like sleep(dt). Well time will move backwards sometimes and dt is negative. I bet this will make most people here worried and they'll think about code they wrote like that (sure did). I have seen systems freeze for example because they end up sleeping for a huge amount of time (negative number was cast to an unsigned huge number).
A small advice on how to improve errors related to time is to abstract it away from algorithms and code as much as possible. Instead of always calling gettimeofday() / time() / now() function to get the current time, in a piece of lower level code, try to pass it in as an argument. That will make code testable.
I have seen fun failing test cases. Something like encoding the current time the test was written and a dt to current time. The test was working for years then started failing eventually because of the hard coded time.
- baq 10y ago> * Time moves forward I agree. Smart library developers seem to agree, too. Example from Python docs: https://docs.python.org/3/library/time.html#time.monotonic https://docs.python.org/3/library/time.html#time.monotonic The only (cough) problem is drilling this knowledge into developers' heads - and as you said, awareness that there even is a problem!
- Iv 10y ago> (negative number was cast to an unsigned huge number) Slightly off-topic pet-peeve of mine: never used unsigned, unless you have an extremely good reason for it. Saving one bit is not one of them. You never know when you will need to do arithmetic on your unsigned values. Time going backwards is a good example of this.
- __s 10y agoThis crops up in Rust's std::time::Duration which has no concept of negative duration
- ioquatix 10y agoIf you think of time like a mathematical vector, the length of that vector can never be negative.. it's always >= 0.. sure, though, in 1D, encoding the direction of that vector as +ve or -ve is pretty convenient.
- cjhanks 10y agoI am the opposite way. In my experience usage of signed where the underlying type is conceptually unsigned introduces subtle bugs. Whereas the defined behavior of unsigned wrap usually causes very obvious stalls and overflows. I have seen so many array access of -1 which never SEGV until you upgrade your compiler or change platform. Also pointers are typically unsigned, I suspect same-type operations are faster for array access... though I never have checked.
- rubber_duck 10y ago>Instead of always calling gettimeofday() / time() / now() function to get the current time, in a piece of lower level code, try to pass it in as an argument. Any code that uses time based scheduling should use a virtual implementation of time/scheduler to allow testing - this way you can say "sleep 10 hours" and then "move virtual time by 10 hours" and actually verify that the timeout is hit without the tests actually taking 10 hours. It also lets you test out logical edge cases such as `<=`, `>=` vs `<`, `>` which is surprisingly tricky with timeouts.
- porker 10y agoGreat idea! But how does one make a virtual implementation of time/scheduler?
- edejong 10y agoEvery function which returns the current time, should be dependency injected with a 'currentTimeService'. This service, during tests, is injected with your mock implementation, and during production with a simple call to 'new DateTime()' or sth like that.
- hermannj314 10y agoI 100% agree. I've pitched this before (during a code review for something) and was laughed at by the team under some guise of YAGNI / developer gold plating. They honestly thought I was joking. Once I explained the issues mentioned in the article, they still thought it was a waste of time. It takes just a few seconds to implement and makes the code so much easier to test / maintain.
- edejong 10y agoTell them we're currently replaying test scenario's involving thousands of truck routes per day (and around a thousand trucks). This allows us to easily recreate bugs and see the effects of fixes, new algorithms, etc. etc. Couldn't do it with some DI on the whole system and simulated time.
- developer2 10y ago>> time will move backwards sometimes Can you please explain this one and hopefully link to an in-depth resource? I imagine you're talking about leap seconds, and/or the possibility that the system time is changed (whether manually or due to an ntpd update that corrects backwards). Are there other sources of this phenomenon?
- prof_hobart 10y agoNot the original poster, but I assume they mean daylight saving. Depending on which kind of clock you're talking about, then for most of the world time goes back by an hour.