Last modified: 2013-11-02 00:58:08 UTC
As is shown at the bottom of the given page, the #time parser function ignores all characters beyond the first newline. If it could instead treat them like spaces, that would be fantastic. Some other functions may also benefit from such a modification, but I'm not sure what they would be. Thanks.
Created attachment 6300 [details] minimal testcase I just remembered that I didn't post the test case from the given URL. I don't want this bug to be ignored just because of that. The expected result is that all three lines output the same thing (middle line should be the same as others); the actual result is in the comments.
It is not ignored, but it is parsed as a time instead (hey, I didn't design this function). Doing something magic here could produce unexpected results for inputs <date>\n<time>, if the time was parsed as part of date.
That's not documented that I can find; in fact, 'H:i:s' is always included on the same line as 'Y m d' at [ http://www.mediawiki.org/wiki/Help:Extension:ParserFunctions#.23time: ]. So it seems that an ignored newline would leave interpretation of date-time strings unaltered. Is there a discrepancy there, or am I not thinking of some special case that the source allows for?
It is: *{{#time: Y m d H:i:s | 1959 }} → 2009 07 05 19:59:00 Input is treated as a time rather than a year. Compare: *{{#time:Y-m-d H:i:s|January 1 2008}} *{{#time:Y-m-d H:i:s|January 1 2008}}
So the purpose is to work around an ambiguity between formats for years and a 24-hour clock. I wonder if an optional input format could be specified as an overriding clarification? But that might require its own bug... Thanks for your time.
Doesn't seem like the benefit of changing this outweighs the risk. Marking WONTFIX.