[03:08:48] why doesn't passing fractional time offsets work (#time parser function)? [03:09:23] {{#time:g:i A|-3.5 hours}} ==> 11:09 AM [03:09:59] {{#time:g:i A|-4 hours}} ==> 11:09 PM [03:10:22] Venezuela is on -3.5 time for chirstsakes [03:10:24] tell bugs.php.net, we just call new DateTime($s, $tz) [03:11:09] thanks TimStarling [03:12:03] TimStarling which PHP do we use? [03:12:20] that's a trick question [03:12:32] I mean, assuming you're just repeating the question on bugs.php.net [03:13:04] no no -- i am more cautious than just ask. i was going to search the database for bugs :) but which PHP version [03:13:47] 5.3.10-1ubuntu3.5+wmf1 [03:13:51] but don't tell them that [03:14:08] thank you. i have not even discovered an interactive forum yet. [03:14:22] maybe I should go to #php if there is one [03:14:52] I wouldn't recommend it [03:15:25] there's ##php but it's mostly just for people who like to tell other people how stupid they are, there's no developers there who might actually fix the problem [03:16:09] so. there is a forum on bugs.php.net? [03:16:35] php > print (new DateTime('-3 hours'))->format("r\n"); [03:16:36] Wed, 20 Mar 2013 00:15:59 +0000 [03:16:36] php > print (new DateTime('-3.1 hours'))->format("r\n"); [03:16:36] Wed, 20 Mar 2013 04:16:03 -0300 [03:16:36] php > print (new DateTime('-4 hours'))->format("r\n"); [03:16:37] Tue, 19 Mar 2013 23:16:08 +0000 [03:16:43] there you go, confirmed it for you on PHP 5.4.12 [03:17:00] anyway, bugs.php.net is a bug tracker [03:17:12] you have the option of either reporting it as a bug, in which case it will be instantly resolved "invalid" [03:17:20] or reeporting it as a feature, in which case it will be ignored forever [03:17:37] sounds like the Venezuelans loose. :( [03:17:40] but at least you will feel like you're contributing to the open source process, right? [03:17:42] lose [03:18:16] if you actually want it fixed, you should email Derick Rethans regularly for a year or so, like I did with for a DoS vulnerability in the same function [03:18:27] s/with// [03:18:28] the -3.1 output is very exotic indeed [03:18:48] for a year, eh [03:18:49] or you can write a patch [03:19:09] hmmm, that sounds like something a developer would do. [03:19:56] or you can file a bug in bugs.php.net, feel that you have done your duty, and then work around it in whatever template you're writing [03:19:57] or you could run away screaming from php, but I don't think that will help you the most in this situation [03:20:58] I was actually trying to debug some user's userbox, and it slippery sloped to testing the #time in my sandbox' [03:21:09] hint [03:21:13] php > print (new DateTime('-3000 seconds'))->format("r\n"); [03:21:14] Wed, 20 Mar 2013 02:30:57 +0000 [03:21:14] php > print (new DateTime('-4000 seconds'))->format("r\n"); [03:21:14] Wed, 20 Mar 2013 02:14:20 +0000 [03:21:14] php > print (new DateTime('-5000 seconds'))->format("r\n"); [03:21:14] Wed, 20 Mar 2013 01:57:44 +0000 [03:21:35] integers make C programmers like Derick happy [03:21:46] so he is using integers internally [03:21:54] yes [03:22:28] I guess he is not hip to time zones having fractional values. Probably never visited New Foundland. Or read about it in Wikipedia. [03:22:48] PHP supports fractional timezones [03:23:02] just not DateTime? [03:23:12] just not relative times expressed as numbers of hours in floating point notation [03:23:30] which is not really meant to be the same thing [03:24:03] so basically, we SHOULD add a usage note to our parser function page that integer number of seconds should be used in these cases [03:24:57] sure, if you like [03:27:00] so, just so I get this right on syntax: instead of {{#time:g:i A | -3.5 hours}} one should attempt {{#time:g:i A | '-12600 seconds' }} ? [03:27:28] minutes would probably work too [03:27:48] Error: Invalid time. in nice bold red [03:28:34] try {{#time:g:i A | -12600 seconds }} [03:29:39] 11:59 PM very nice [03:30:26] thank you, Tim [03:30:35] no problem [06:01:39] I'm getting an error trying to save an edit at [[Talk:Main Page]] on en.wiki. [06:01:42] Over https. [06:02:29] > [06:02:30] Last attempted database query: (SQL query hidden) [06:02:30] Function: WikiPage::updateRevisionOn [06:02:30] MySQL error: 1205: Lock wait timeout exceeded; try restarting transaction (10.64.16.6) [06:02:37] > [06:02:49] I'll just keep trying until it works, of course... [06:03:11] Okay, it saved. [06:03:14] Edit conflicted myself. [08:29:20] Susan: which shouldn't happen. [08:30:00] Right. [08:30:09] Susan: was it a section edit? [08:30:18] https://bugzilla.wikimedia.org/show_bug.cgi?id=26821 [08:30:50] When I triaged existing reports, unsuppressed self-conflicts all seemed to be section edits. [08:31:46] Well, or not. https://bugzilla.wikimedia.org/show_bug.cgi?id=34423 [08:58:02] Nemo_bis: I was adding a section. [08:58:10] There seemed to have been some database hiccup as I did. [08:58:18] Then I went back in my browser and tried to resubmit. [08:58:24] And at some point, self-edit conflicted. [08:58:26] It's not a big deal. [09:14:40] Susan: thanks for your proof reading of my bug reports :-] [09:21:13] :-) [09:24:33] https://meta.wikimedia.org/wiki/User:Sue_Gardner/Wikimedia_Foundation_Guiding_Principles [16:07:50] DaBPunkt, can I speak to you? [16:09:49] Can somebody with experience with toolserver help me? [16:09:58] Cyberpower678: why not? maybe you should ask in #wikimedia-toolserver [16:10:12] also, don't ask to ask. just ask [16:10:19] jeremyb_, thanks for that. [16:10:22] I can [16:10:33] I can't get public_html to work. [16:10:40] What am I doing wrong? [16:11:21] ack wrong channel. [17:32:09] [74e1e923] 2013-03-20 17:32:00: Fatal exception of type MWException [17:32:13] on watchlist on Meta [17:32:52] [76b26f78] 2013-03-20 17:32:31: Fatal exception of type MWException [17:32:53] hah [17:32:53] yes [17:33:10] my page works fine now [17:33:16] works with Italian interface [17:34:59] The error message for guillom's exception: 2013-03-20 17:32:31 mw1025 metawiki: [76b26f78] /wiki/Template_talk:Draft Exception from line 352 of /usr/local/apache/common-local/php-1.21wmf11/includes/cache/MessageCache.php: Could not acquire 'metawiki:messages:en:status' lock. [17:35:32] That's the page, yes [17:36:23] ah, that was fixed in master [17:36:30] (supposedly) [18:41:58] Nemo_bis: I got another self-edit conflict at [[w:en:Talk:Main Page]]. [18:42:05] I'm beginning to think it's something to do with that page. [18:42:11] Maybe its high number of page watchers or something. [18:46:48] Susan: you mean that the edit conflict suppressor feels embarassed for the excessive amount of eyeballs and does mistakes? [18:46:52] Entirely possible. [18:52:35] Nemo_bis: "and makes mistakes" [18:58:49] jeremyb_: yes, thanks, that always requires me to think a couple secs [19:16:09] Hi guys. [19:16:30] I have a question about querying from the WP database. [19:16:49] How can I connect to WP MySQL database? [19:19:31] https://wiki.toolserver.org/view/FAQ [19:19:32] TahaB: ^ [19:19:36] Read about the Toolserver? :-) [19:19:40] You may want to get an account there. [19:19:47] Ok, [19:19:50] Thanks. [19:19:57] I'll read and come back later. [20:31:33] greg-g: everything clear for syncing CentralAuth? [20:32:54] pgehres: asking Reedy and aude in -operations [20:33:02] thanks for checking [20:33:03] * pgehres looks there too [20:33:52] still scapping [20:34:23] pgehres: ^ [20:34:25] kk, /me waits [20:34:37] shouldn't be too far off [20:36:12] it's onto the snapshot hosts now [20:36:51] not a problem :-) [20:36:54] Reedy: just curious, was it a late start or did something snag you up? [20:37:19] ohh [20:37:22] greg-g: Timezones [20:37:22] Reedy: when ready , we'll want https://gerrit.wikimedia.org/r/#/c/54909/ again for test2 [20:37:29] You're still -7 [20:37:41] 18:00-20:00 [20:37:47] when i'm used to 19:00-2100 [20:37:55] And i think the wikidata guys were expecting the same as me ;) [20:39:04] Reedy: *grumble grumble* timezones *grumble* [20:39:05] sorry [20:39:09] normally, this would be the last half an hour of the window ;) [20:39:16] * aude demands daylights savings be abolished :D [20:39:21] too confusing [20:39:24] amen to that [20:39:52] real 42m14.669s [20:40:14] wow [20:40:22] user 5m40.197s [20:40:23] sys 0m43.151s [20:41:23] pgehres: Should be good to go now [20:41:34] awesome, thanks Reedy [20:42:25] Reedy: last thing (no hurry) is to check the job queue [20:42:37] which one where? [20:42:58] doesn't matter.... any wikipedia [20:43:14] probably better leaving it for half an hour to an hour then [20:43:21] ok [20:43:35] we have 2 cronjobs which is not magic but should improve the lag somewhat [20:43:42] the lag is in the dispatcher [20:43:58] change notification table, but also want to be sure the clients are okay [20:44:14] * aude wish for a way to check that myself.... [20:44:45] we have a bug for that [20:45:11] https://bugzilla.wikimedia.org/45533 [20:54:09] greg-g: i'm done. thanks [20:55:21] pgehres: thank you! [21:35:28] Testing bin/dologmsg [21:41:57] notpeter: Was the mysql-database of the s1-server re-setup during the last hour? [21:42:28] DaBPunkt: binasher has been upgrading things to mariadb [21:42:36] I would guess that that is the change that you're seeing [21:42:56] looks like it is not compatible with mysql (at least with 5.1) [21:43:19] hhhmmmm [21:43:22] this seems like an issue [21:43:30] I will skip these lines, but maybe you should look at your servers too [21:44:02] DaBPunkt: hmm? [21:44:59] DaBPunkt: what host are you replicating s1 from? [21:45:14] db63 [21:45:50] interesting [21:45:56] what queries did you skip over? [21:46:05] the s1 master is db1017 [21:47:44] binasher: http://pastebin.com/AD9icEAH [21:48:15] we can not reach the servers in virgina so we use the one in tampa [21:49:32] DaBPunkt: ah, ok [21:49:52] i should probably disable binlogging before running mysql_upgrade [21:50:22] DaBPunkt: is toolserver on mysql 5.1? i thought 5.5 for some reason [21:52:05] binasher: 5.1 (both solaris and debian) [21:52:39] DaBPunkt: is replication ok after skipping over those few queries? [21:57:37] "Cannot load from mysql.proc. The table is probably corrupted" mm [21:59:05] cludes/GlobalFunctions.php 'Fix wfWaitForSlaves() so the parameter actually works correctly' [22:00:59] !log pgehres synchronized php-1.21wmf11/includes/GlobalFunctions.php 'Fix wfWaitForSlaves() so the parameter actually works correctly' [22:01:05] Logged the message, Master [22:01:23] !log pgehres synchronized php-1.21wmf12/includes/GlobalFunctions.php 'Fix wfWaitForSlaves() so the parameter actually works correctly' [22:01:29] Logged the message, Master [22:01:50] binasher: looks like our mysql.proc-tables differs now [22:09:47] binasher: I have run mysql_upgrade and that seems to have fixed the problem with mysql.proc [22:09:57] replication is running again [23:35:39] !log asher synchronized wmf-config/db-pmtpa.php 'returning s1 servers' [23:35:51] Logged the message, Master [23:36:27] !log asher synchronized wmf-config/db-eqiad.php 'pulling es100[69]' [23:36:39] Logged the message, Master [23:51:22] !log asher synchronized wmf-config/db-pmtpa.php 'returning s2 servers' [23:51:33] Logged the message, Master [23:52:06] !log asher synchronized wmf-config/db-eqiad.php 'returning es100[69]' [23:52:16] Logged the message, Master