Last modified: 2011-12-01 14:56:10 UTC
On test.wiki my block log shows (I have cut unimportant stuff): 18:50, 8 December 2009 Behalten blocked Beau with an expiry time of 19:26, 4 October 2011 05:58, 2 June 2009 Beau blocked Beau with an expiry time of 19:26, 4 October 2011 03:05, 29 March 2008 Beau blocked Beau with an expiry time of 19:30, 4 October 2011 00:28, 2 February 2008 Beau blocked Beau with an expiry time of 19:26, 4 October 2011 Those times are invalid. I have executed a query on toolserver: mysql> select log_timestamp, log_params from logging where log_action='block' and log_title = 'Beau'; +----------------+---------------------------+ | log_timestamp | log_params | +----------------+---------------------------+ | 20080201222844 | 1 minute nocreate | | 20080329010543 | 5 minutes nocreate | | 20090602035853 | 1 minute nocreate,noemail | | 20091208165038 | 1 second noautoblock | +----------------+---------------------------+ 4 rows in set (0.15 sec)
Can you elaborate why they are invalid?
Take a look at a date when the block was placed. For example entry: 18:50, 8 December 2009 Behalten blocked Beau with an expiry time of 19:26, 4 October 2011 has corresponding row in database: | 20091208165038 | 1 second noautoblock | However the expiry times suggests that the block was active for almost 3 years.
Cannot reproduce on trunk. The block log doesn't show absolute timestamp for relative length blocks.
Take a look at test.wiki. I have provided URL.
Not all entries are affected. For example, on https://pl.wikipedia.org/w/index.php?title=Specjalna%3ARejestr&type=block&user=&page=User%3Abeau&year=&month=-1&tagfilter= only the first entry is invalid, the last one is correct. it is only a guess, but maybe it happens for a very short blocks?
Does it only happen with old log entries done few years ago, or with new ones too?
Yes. I have blocked myself for 2 minutes on test.wiki. And the expiry time is changing as I refresh block log. What is interesting it shows invalid time - it does not take into account the time zone I set in preferences. 18:31, 5 October 2011 Beau blocked Beau with an expiry time of 16:36, 5 October 2011
Only for your Information: Works on the api: http://test.wikipedia.org/w/api.php?action=query&list=logevents&letype=block&lelimit=max&letitle=User:Beau (timestamps in UTC)
Confirmed on fr.wiki: when a user is blocked with a duration, the expiration time displayed in the logs changes minute to minute. It looks like the expiration date is computed from the current time and not from the block time. For instance take a look at User:NakoRrRrRrR which was blocked for 8 months. The API <http://fr.wikipedia.org/w/api.php?action=query&list=logevents&letype=block&lelimit=max&letitle=User:NakoRrRrRrR> indicates the last block expires on 2012-06-05T20:46:12Z The block log looked at at 20:53 GMT today has an expiration date of 5 june 2012 at 20:53 The block log looked at at 20:55 GMT today has an expiration date of 5 june 2012 at 20:55
LogPage has the code $wgLang->translateBlockExpiry( $params[1] ) which uses the current time for any relative expire values. This code is old...implying that such relative values were likely converted to absolutes in the past. The API does: wfTimestamp( TS_ISO_8601, strtotime( $params[0], wfTimestamp( TS_UNIX, $ts ) ) ); ...with $ts as log_timestamp. This avoids the problem of dates changing as it is relative to when the block happened. To fix this one can update the DB (making them absolute using log_timestamp as the base time) or change LogPage to be more like the API.
r91770 changed Language::translateBlockExpiry to include a strtotime() to resolve relative timestamps against the current time, which is rather wrong since this gets used on old dates in logs.
Reverted that change in r99155 on trunk.
r99154 rather (r99155 fixes release notes)
