Last modified: 2011-04-30 01:16:45 UTC
We run MediaWiki on a virtual machine (VMWare) and occasionally encounter bad revision times since the VM has a hard time keeping the time synced correctly. Basically, several hours pass in a matter of minutes, someone makes an edit, several more hours pass and the time re-syncs when it thinks that it is midnight. That sets the current time to a point before the time it thinks the revision was made. Craziness ensues. I appreciate this is a bit of an edge case from virtualization, but it would still be nice to see fixed. I feel that virtualization only exposed this, and there may be other ways to reproduce this. (And yes I know there are ways to keep VM times in sync, I would just prefer not to go into detail here about why we don't.) Steps to reproduce: -At time X, make an edit on a page -Set the server's time to X - 2:00 -Navigate to the page that was edited -Check the history of the page, it should say the the edit occurred two hours ahead of the server's time -Navigate back to the page -Attempt to login Expected Result: The user is logged in Actual Result: The page appears to refresh, but the user is not logged in -Click view source (It now appears that you are logged in) -Make some edits and submit Expected Result: The edits should appear on the page Actual Result: The page remains the same -Check the history on the page Expected Result: The edit just made should appear at the top of the list Actual Result: The original edit is at the top, with the most recent one under since it was made at an earlier system time Ideal Fix (In my mind): The user should be able to login regardless of the server's time being behind the revision time. Additionally, and this is certainly discussable, if an revision time stamp is ahead of the server time at the time of an edit, the revision time should be modified to the current time to keep edits in chronological(Real-Time) order.
While searching through other bugs I noticed bug 11372 and thought that it may be related.
I'm going to take the liberty of marking this bug invalid on the basis that, well, nothing's going to work right if you're fiddling with the clock in this way. :) (Virtualization _should_ not be sending your clock backwards unless you're doing something very odd indeed, like putting all your storage on an external server so it persists, then reverting the VM state to a previous snapshot, *and* not having the clock set to synchronize properly.) A couple of likely causes of the viewed behavior off the top of my head: 1) Your session states are getting utterly corrupted by the broken time situation or 2) Login worked just fine, but your browser is telling the server it's already seen a more recent version of the page so the server quite legitimately responds with a '304 Not Modified'. Since all such caching behavior is based on having clocks set consistently, I can only recommend fixing your VM'c configuration to update its clock correctly on suspend/resume.
