How could a time warp attack be prevented? jarpian explains what a time warp attack (AKA zeitgeist attack) is:


  This is a 51% attack where the attacker sets the block timestamps artificially to lower the difficulty, allowing him to profit more coins than his hash rate would warrant. It works because the difficulty adjustment formula is based purely on timestamps that can be chosen quite freely by the attacker. In particular, the timestamps are not required to be in increasing order. ArtForz explains the attack in detail here.
  
  This attack was used against the new Geist Geld block chain. Geist Geld difficulty adjusts every 16 blocks making the chain particularly vulnerable against this attack. An attacker targeting Bitcoin would have to mine a full set of 2016 blocks at the current difficulty before starting to get any benefit compared to a "normal" 51% attack.


Obviously, performing this attack would be horrendously expensive. (Coinometrics places the cost at about $463 million at time of writing.)

However, if you were successful, you could lower the difficulty and increase the block rate by a factor of 4 every 2 weeks, letting you mint coins more than every 10 minutes. 

The obvious way of fixing this - changing the block retarget period from (2016*n, 2016*n + 2015) to (2016*n, 2016*n + 2016) is problematic. Blocks produced by the new implementation would be invalid in the old implementation, and vice-versa. (Source)

So, how could a time warp attack be prevented in a non-disruptive way?
The simple solution is a soft fork that requires each block's time be equal to or greater than the time of the previous block on the block chain.  That is, time on the block chain can't go backwards.

If time can't go backwards, then the attacker can't artificially lower difficulty except by mining blocks with times in the future, and the network already rejects blocks more than 120 minutes into the future.

This proposal is a soft fork because non-upgraded miners will accept a more difficult chain whose times only increase or stay the same.  If implemented the same way as BIP34, the supermajority of hash rate would be upgraded before the new rule was applied, minimizing disruption.