The timestamp can be manipulated to a small degree (unless a majority of miners are colluding) since overtly abnormal timestamps will be rejected by other mining nodes.

block.number is presently a very unreliable method of measuring time (even for medium-term applications). Firstly, the time between blocks is already changing regularly due to the difficulty bomb. Then, there is the proposed delay of the difficulty bomb -- which means you have to figure out whether it will happen. Then there's a potential for a change in block time at some other point in the future -- and all bets are off when we have proof of stake.

For short-term intervals (and before integral steps in difficulty change from the difficulty bomb are accounted for), you can use the average time for a block to be mined and multiply to create a time measurement. Approximate time elapsed is average time multiplied by block time.

The timestamp can be manipulated to a small degree (unless a majority of miners are colluding, in which case all bets are off) since overtly abnormal timestamps will be rejected by other mining nodes.

block.number is presently a very unreliable method of measuring time (even for medium-term applications). Firstly, the time between blocks is already changing regularly due to the difficulty bomb. Then, there is the proposed delay of the difficulty bomb -- which means you have to figure out whether it will happen. Then there's a potential for a change in block time at some other point in the future -- and all bets are off when we have proof of stake. So not only would I not recommend using block.number for counting time for medium- and long-term periods, it is not really possible, unless you can predict the future.

For short-term intervals (and before integral steps in difficulty change from the difficulty bomb are accounted for), you can use the average time for a block to be mined and multiply to create a time measurement. Approximate time elapsed is average time multiplied by block time.