Last modified: 2013-11-02 00:54:19 UTC
Related to bug 28655 and bug 13357, this apply to pure-numeric integer date/time objects only, ie. "truncated timestamps", especially those of 4 or 6 digit length. Regardless of PHP bug causing some misinterpretations, those issues can be overridden applying {{padright: {{padright: «truncated timestamp» | 8 | 01 }} | 14 | 0 }} Thus converting all pure-numeric integer objects in complete 14 digit timestamps. Current outputs: {{#time: Y | 1998 }} → 1998 (partially fixed since rev:86805) {{#time: Y M d H:i:s | 1998 }} → 1998 Aug 19 00:00:00 (expected 1998 Jan 01) {{#time: F Y | 200611 }} → August 2011 (expected November 2006) {{#time: Y M d H:i:s | 200615 }} → 2011 Aug 19 20:06:15 (expected error) {{#time: Y M d H:i:s | 199804 }} → Error (expected 1998 Apr 01 00:00:00) Now using padrighted inputs: {{padright: {{padright: 1998 | 8 | 01 }} | 14 | 0 }} → 19980101000000 {{padright: {{padright: 200615 | 8 | 01 }} | 14 | 0 }} → 20061501000000 {{padright: {{padright: 199804 | 8 | 01 }} | 14 | 0 }} → 19980401000000 {{padright: {{padright: 19980425340712 | 8 | 01 }} | 14 | 0 }} → 19980425340712 {{#time: Y M d H:i:s | 19980101000000 }} → 1998 Jan 01 00:00:00 (OK) {{#time: Y M d H:i:s | 20061501000000 }} → Error (OK) {{#time: Y M d H:i:s | 19980401000000 }} → 1998 Apr 01 00:00:00 (OK) As right padding forces the system to make a date interpretation (instead of time interpretation) of ambiguous 4 or 6 digit integer input data, we should have a way to opt to do this pre padding, or not. This option may be achieved by a new 'xd' flag ('d' related to date interpretation). It should be a toggled flag like xN and it should work as follows: {{#time: xdY | 2006 }} → 2006 {{#time: xdF Y | 200611 }} → November 2006 {{#time: xdY m d H:i:s | 200615 }} → Error {{#time: xdY m d H:i:s | 199804 }} → 1998 04 01 00:00:00 {{#time: xdY m d H:i:s | 1998 }} → 1998 01 01 00:00:00 This was originally posted a couple of years ago at http://www.mediawiki.org/wiki/Help_talk:Extension:ParserFunctions#Request:_new_flag_to_force_date_interpretation_in_.23time
Since bug 28655 and bug 13357 are both fixed now, it doesn't seem like there is really a need for this work around any more.