That's because the runtime limit was changed from number of samples to time in minutes. The Windows app was not yet updated, so it reads 3 hours as 180 samples x 40 seconds each = 120 minutes. On Linux everything should be fine, as the app there already reads the prefs as runtime in minutes.

There is another issue with the run time setting, when the BOINC core client runs under very high load (a lot of heavyweight CPU or GPU tasks), the timing functions available from BOINC API are off by a small amount of time.
Usually that's just microseconds on each call which adds up to a couple of seconds or perhaps minutes per average length workunit, so that's nothing to worry about.

There was one extreme case reported by Szopler; when running fightmalaria, it stresses the BOINC core so much that the API calls take much more time than expected.
Under this conditions boinc_sleep(1.0) took around 4.0 seconds to execute (average) during my trials with test app, which resulted in completely wrong runtime and sample_time jumping so wildly, that eventually the validator didn't like the output and set the WU as invalid.
The 1.70 app (which is under tests now) fixes that partially by watching it's own timer instead of blindly trusting the BOINC core, however it's still not perfect and the runtime will increase under very high load (not to some ridiculous values anymore), that's unavoidable because the app has to call the API frequently.