Last modified: 2011-02-08 21:56:37 UTC
See URL, there is a difference between REVISIONTIMESTAMP and the substituted LOCALTIMESTAMP from 1 second. This can happen, when the parsing of that page is not in the same second than the storing in database. This can affect all timevariable (LOCAL* and CURRENT*, maybe parser function #time/timel).
Is this something we care about?
(In reply to comment #1) > Is this something we care about? I think so... But feel free to WONTFIX this. Than this is for documentation only.
Revision timestamp is the time the last revision was stored. Localtimestamp is the time the page was last parsed. If one purges the page (action=purge) afaik the localtimestamp will be updated (among othere things), but revisiontimestamp will stay the same. When somebody clicks "Save" the time the request is recieved will be marked as the revisiontimestamp (the time you see on the History page). Then the rendering starts and it can sure take longer then a second sometimes (or even if the rendering only takes 3 miliseconds, if after 2 miliseconds the clock completes the minute, the localtimestamp right after saving could be one minute more). So I dont think this is a bug, nor should it be changed.
(In reply to comment #3) > Revision timestamp is the time the last revision was stored. > Localtimestamp is the time the page was last parsed. > If one purges the page (action=purge) afaik the localtimestamp will be updated > (among othere things), but revisiontimestamp will stay the same. The different in this bug is, that the timestamp get substituted and so the real time goes into the wikitext and purge has no effect.
