I was playing with faketime the last few days mainly to implement features needed by ReproducibleBuilds, which is an initiative in Debian for providing binary packages that can be regenerated with the exact same content. Some build steps place timestamps in the resulting binaries, thus we may have to make time perceived by the build process move at a deterministic rate starting from a predetermined point in time.
This is why faketime got support for advancing time with each time(), gettimeofday(), etc. call. Another approach would be recording timestamps perceived by the first build and replaying them in the same order to successive builds. If the build is deterministic apart from the timestamps, this should result in the same binary package for each build.
While playing with faketime I could not resist implementing a few things which may not have been absolutely important for reproducible builds, but were so much fun. The nanosecond resolution of timestamps made games playable at slower or faster speeds making very hard games easier or easy games harder. Jump’n’bump just became insanely funny at 200% speed:
faketime -f "+0 x2" jumpnbump
Speeding up sleep()-s can also be useful in daily work. If your application calls sleep() often it may significantly slow down testing, but faketime is now able to shorten sleeps, too, speeding up testing such applications!
I hope this won’t be used for the whole package build. Messing with gettimeofday() may confuse automated test suites that are run during build.
Faketime used as a wrapped tries to fake all time related functions consistently when speeding up or slowing down time. It should not be different from running the build on a slower or faster machine, but I agree that time based tests can be very fragile in these cases even without faketime.
The ReproducibleBuilds project is at a very early stage and we need to test a lot of package builds to find the ones sensitive to faking time. If you have some in mind please share them, or you can test latest faketime from GitHub if it causes any problem.
I think the actual build part of the package builds should work with faketime (even with faketime -f ‘+0 i1’ ), and we could disable faking time for make test if needed.
Is it nice to play fake time, or it is nice to use a recorded time than to use like this, just giving some points of view. What is the difference of a fake and a recorded time?
Faketime has several modes of operation, see https://github.com/wolfcw/libfaketime/blob/master/README .
Generally it changes how an application perceives time progressing. It can freeze the clock at a specific time stamp, it can start the clock
form a specified time stamp and make it run at “normal” speed or it can even adjust the speed with a constant, for example making time going two times faster or slower for the application. It is achieved by capturing time related calls and returning modified values based on the system’s running clock.
This is what I used for capturing the video and probably changing the speed of time is the most interesting feature for using faketime with games.
One new feature is recording all the timestamps which were returned to the application to a file and replaying the timestamps from this time in successive runs. It may be interesting for running small deterministic programs where we want to make every run independent from the system’s clock.
For example you can do this:
$ FAKETIME_SAVE_FILE=time.sav faketime -f '+0' bash -c 'date;sleep 1; date;date'Thu Jan 23 14:11:43 CET 2014
Thu Jan 23 14:11:44 CET 2014
Thu Jan 23 14:11:44 CET 2014
$ FAKETIME_LOAD_FILE=time.sav faketime -f '+0' bash -c 'date;sleep 1; date;date'
Thu Jan 23 14:11:43 CET 2014
Thu Jan 23 14:11:44 CET 2014
Thu Jan 23 14:11:44 CET 2014
$ FAKETIME_LOAD_FILE=time.sav faketime -f '+0' bash -c 'date;sleep 1; date;date'
Thu Jan 23 14:11:43 CET 2014
Thu Jan 23 14:11:44 CET 2014
Thu Jan 23 14:11:44 CET 2014