[00:03:30] I'm sure $this->mTimestamp is already a YYYYMMDDHHSS string but we cast it to that same format via an object that runs a bunch of regex checks and then sprintf's to a slightly different format, creates a DateTime object and then formats back to the original input format. [00:03:57] E_TOO_MANY_STEPS [00:18:37] bd808: did you look at the @author of MWTimestamp? [00:18:59] doh [00:19:16] * bd808 bites tongue [00:20:27] But even then, why would we cast the date string from the db back to the format of the date string from the db? [00:21:06] Was there a legacy date format stored in the db that isn't TS_MW format? [00:22:02] I don't think so [00:22:30] rev_id=1 has a ts of 20020126142519 [00:22:51] Revision::getTimestamp() should just return $this->mTimestamp and be done with it them [00:22:57] s/m/n/ [00:23:27] ohhh [00:23:28] postgres [00:23:40] does it use "real" dates? [00:23:45] I think so [00:23:57] I see stuff about oracle too [00:24:00] function timestamp( $ts = 0 ) { [00:24:00] return wfTimestamp( TS_POSTGRES, $ts ); [00:24:00] } [00:24:07] in DatabasePostgres [00:24:15] * bd808 shivvers [00:24:30] really lame dudes, really lame [00:24:57] I wonder how many bugs are caused by that difference [00:25:07] no wonder that postgres is always broken [00:25:24] s/always/often/ whatever [00:25:48] The data model should not vary by storage medium [00:26:00] That's madness [00:26:14] bd808: that's abstraction! [00:26:17] :> [00:26:35] MatmaRex: I think you picked up a naughty word on the playground [00:27:08] The proper abstraction for dates in PHP is the DateTime object [00:27:29] but we only use that in passing [00:29:01] Unless you can run a wiki in a non-gregorian calendar dates don't need to be abstracted. and if they do need to differ for the storage layer that difference should be removed immediately by the model layer [00:29:38] The model should not have variable contents based on the storage engine, that's tight coupling [00:30:14] <^d> How does that $wgArticle work? That's been removed. [00:30:23] But there I go expecting a separation of model and storage :/ [00:30:28] ^d: it creates a new Article object and calls it $wgArticle [00:30:33] <^d> Oh pfft. [00:30:39] <^d> There's a couple of extensions still doing that. [00:30:39] * bd808 is rewriting the whole thing [00:30:42] <^d> You can call it anything. [00:37:40] The diff looks like confetti, but the raw file reads better to me -- https://gerrit.wikimedia.org/r/#/c/177948/ [00:39:07] <^d> Finally got an answer from Evan about canceling a queued task like we found earlier. [00:39:16] <^d> It's a bug, not a design decision :p Task filed upstream. [00:39:30] excellent [00:40:16] ^d: have all the extensions been imported now? [00:40:43] <^d> still daemon tasks to parse all the commits. [00:40:52] oh, and skins? [00:40:55] <^d> but the actual "give all the repos to conduit so you can start importing" is done. [00:41:01] <^d> Not yet, I just did extensions today. [00:41:17] ok [00:43:14] <^d> PhabricatorRepositoryGitCommitMessageParserWorker 183,006 [00:43:18] <^d> We have a ways to go :) [00:50:44] <^d> legoktm: I skipped mediawiki/extensions/normal and mediawiki/extensions/skins [00:50:53] <^d> Former should probably be in mediawiki/php/* [00:51:08] I thought I killed extensions/skins [00:51:10] <^d> Latter is probably superseded by the mediawiki/skins meta repo. [00:51:16] <^d> Nope, it's there. [00:51:21] argh [00:51:51] I think I already copied all the code though [00:51:58] <^d> Might have? Dunno. [00:52:01] <^d> Repo's still there. [00:52:29] * legoktm empties repoi [00:52:31] repo* [00:53:59] <^d> No need, can just delete it [00:54:07] but it has history? [00:54:39] deleting stuff makes all the gerrit changes go away right? [00:55:22] <^d> Well bleh, don't worry about it then. [00:55:38] <^d> I only care about stuff that's deletable, not just unused. [00:56:45] https://gerrit.wikimedia.org/r/177954 [00:59:36] TIL my yaml extension is copy-pasta'd into hhvm -- https://github.com/facebook/hhvm/tree/master/hphp/runtime/ext_zend_compat/yaml [00:59:52] <^d> yay ezc! [01:01:30] I think I remember T.im saying something about using it for the tests. It just never dawned on me that it was folded in [01:03:56] I seen some reasonable changes they made to the code too. too bad they didn't upstream them :/ [01:05:18] <^d> The flow of code from PHP to HHVM is one way right now I'm afraid. [01:05:20] https://github.com/facebook/hhvm/issues/4385 https://github.com/facebook/hhvm/issues/4392 dupes? [01:05:55] <^d> gj bd808 AaronS [01:06:38] doh. I didn't see Aaron's [01:09:20] * bd808 closed my with a ref to Aaron's [01:11:08] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#823008 (10jeblad) Thanks, the important thing is that nothing is lost. If that means we told some journalist we had more articles/edits than we in fact did, then we can live wit... [01:22:41] \o night all. time for pizza, beer and football [01:25:45] o/ [05:14:22] 3MediaWiki-Core-Team: Isolate throughput issue on HHVM API action=parse - https://phabricator.wikimedia.org/T758#823116 (10ori) I wrote an HNI extension for just `tidy_repair_string()` and pushed it to [[ https://github.com/wikimedia/mediawiki-php-tidy/blob/hni/ext_tidy.cpp | the hni branch of the repository ]].... [08:27:54] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#823176 (10Liuxinyu970226) [13:20:37] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#823250 (10Nemo_bis) [13:21:58] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#823251 (10Nemo_bis) 5Open>3declined a:3Nemo_bis > I imagine Core, though, should really look into how exactly Special:Statistics overcounted edits for months on end. Will... [13:41:27] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: robots.txt Last Modified header is wrong - https://phabricator.wikimedia.org/T76915#823275 (10Liuxinyu970226) [14:15:14] 3MediaWiki-Core-Team: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#823294 (10Qgil) [14:20:52] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#823298 (10Qgil) A possible solution: * Create #MediaWiki-Core as a project umbrella (we could even consider the use of the 'umbrella' icon, still with violet ba... [14:22:26] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#823301 (10Ciencia_Al_Poder) [16:35:33] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#823334 (10Ironholds) [16:36:42] 3MediaWiki-Core-Team: Sudden drop in number of articles on nowiki on Nov29 (by 34k articles) - https://phabricator.wikimedia.org/T76356#798625 (10Ironholds) [17:14:31] 3MediaWiki-General-or-Unknown, MediaWiki-Core-Team: Allow to search tasks about MediaWiki core and core only - https://phabricator.wikimedia.org/T76942#823351 (10fbstj) [23:06:02] 3MediaWiki-Core-Team: Convert old 1.23wmf* and 1.24wmf* deployment branches to tags - https://phabricator.wikimedia.org/T1288#823538 (10Krinkle)