Yes. The only defense is a sheer expense of doing that attack. Also note that attacking time over a significant period would also attack the difficulty, so the stupid attacker (speeding up the time) will actually attack itself through the difficulty increase.
There's some sort of additional sanity check, a valid block cannot have a timestamp that is off by more than two hours from the median of the last ten blocks or something like that.
I can verify that I have verified that this code is there and it works.
// Check timestamp
if (block.GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return state.Invalid(error("CheckBlock() : block timestamp too far in the future"),
REJECT_INVALID, "time-too-new");
You can mine a testnet block with your computer clock set 119 minutes into the future, but if you were to timestamp a block over two hours ahead, the network (which all have a similar opinion of the time) will reject the block (as in ignore the block and no further blocks will be built on it), at least until enough time has elapsed that the block can be retransmitted after it does comply with network time rules. This is just based on each miner's clock, which are not allowed to be off from network time consensus by more than five minutes without a warning.
The network consensus time is very accurate. I run NTP and never get more than
nTimeOffset = -2 (+0 minutes) in the logs.
Since there is very little latitude in block timestamps that will be accepted, this does not give the miner much room in fudging a timestamp on the retarget block - two weeks (336 hours) +/- 1 hour. Here you can see the debug.log of retargeting being done:
2014-09-14 23:03:37 nActualTimespan = 1112235 before bounds
2014-09-14 23:03:37 GetNextWorkRequired RETARGET
2014-09-14 23:03:37 nTargetTimespan = 1209600 nActualTimespan = 1112235
2014-09-14 23:03:37 Before: 182815ee 00000000000000002815ee000000000000000000000000000000000000000000
2014-09-14 23:03:37 After: 1824dbe9 000000000000000024dbe917e45e45e45e45e45e45e45e45e45e45e45e45e45e
