Hacker News Reader

>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.

Great idea! But how does one make a virtual implementation of time/scheduler?

Every 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.

I 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.

Tell 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.

What edejong said basically, Rx library uses this concept really well - you can see for example in .NET implementation [1] how the scheduler interface looks like. They basically abstract system timer and scheduling tasks, then you can implement you own virtual time implementation where current time is just a property that you can manually set, and when you change it you go trough the list of scheduled tasks and see if you need to execute any before the new current time.

[1] https://msdn.microsoft.com/en-us/library/system.concurrency....

Our solution in c# with dependency injection looks like this.

Any class that needs to know the time has the following object injected in.

  public interface IDateTime
    {
        DateTime UtcNow { get; }
        DateTime Today { get; }
    }

StructureMap is configured to pass in the following concrete implementation.

  public class DefaultDateTime : IDateTime
    {
        public DateTime UtcNow
        {
            get { return DateTime.UtcNow; }
        }

        public DateTime Today
        {
            get { return DateTime.Today; }
        }
    }

Obviously you can expand this to include local time, we haven't in order to prevent accidental use of Now when you mean UtcNow.

All of our tests inherit from a base test that does various set up stuff (clear down the db in integration tests for example). One of the things it does is swap out DefaultDateTime with this...

  public class TestDateTime : IDateTime
    {
        private DateTime _testDateTime;

        public TestDateTime(DateTime testDateTime)
        {
            _testDateTime = testDateTime;
        }

        public void ChangeTimeTo(DateTime testDateTime)
        {
            _testDateTime = testDateTime;
        }

        public DateTime UtcNow
        {
            get { return _testDateTime.ToUniversalTime();         }

          public DateTime Today
        {
            get { return _testDateTime.Date; }
        }
    }

Where _testDateTime is set to be sometime in August (always a good idea if you're developing in the UK!). This has the added advantage of making test runs deterministic (at least in this respect) even if you're not doing a time related test.

Sorry, what's the connection between August and the UK? Based in the US, but I can't think of a specific month I'd want my tests to run in.

Not sure for sure but August is probably the least rainy/nasty month in England

It's summer time - during the winter the UK runs on UTC, so if you've forgot to do a timezone conversion you don't spot it until the clocks change in spring. Having tests use the time in summer make this easier to spot.

Shameless plug: libfaultinj [1] is my library that intercepts libc calls and does bad behavior (that you specify) instead/in addition.

It doesn't support this use case. Yet [2].

[1] https://github.com/androm3da/libfaultinj

[2] https://github.com/androm3da/libfaultinj/issues/2

Oh awesome. That is good stuff. I will have to try it.

This is quite right. It is actually just a special case of "singletons are evil". People sometimes don't notice that "the system" is the biggest singleton of them all.

Now all we need to do is get rid of the filesystem and all other databases...

I'm guilty of not following this enough. Hopefully I've learned my lesson - never put a NOW() in a sql query.

> (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.

This crops up in Rust's std::time::Duration which has no concept of negative duration

If 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.

I 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.

> * 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

The only (cough) problem is drilling this knowledge into developers' heads - and as you said, awareness that there even is a problem!

>> 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?

Not 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.