Page MenuHomePhabricator

curious date parameter parsing for #time
Open, LowPublic

Description

Author: a.d.bergi

Description:
Possible duplicate: bug 13357 ?

I'm generating a ISO timestamp for the #time parser function in [[de:template:ME(S)Z2UTC]]. Yesterday I got notified that it doesn't work (any more?), the input

{{#time:c|2012-3-11T-1:00}} gives 2012-03-11T07:00:00+00:00.

That's OK, negative hours needn't work (even as {{#time:c|2012-3-0}} returns 2012-02-29... "correctly"). However, I wondered where these 7 o'clock come from. The error is reproducable and does not depend on the current time. Any suggestions?

I also did some further investigation and tried out some inputs:

  • 2012 - 2012-03-12T00:00:00+00:00 (current date)
  • 2012-1 - 2012-01-01T00:00:00+00:00 - OK
  • 2012-1T
  • 2012-1T-10 - 2012-01-01T07:00:00+00:00 - there's the seven again!
  • 2012-1T0:0 - 2012-01-01T00:00:00+00:00 - as expected
  • 2012-1T0 - <error>, OK
  • 2012T - 2012-03-13T03:12:00+00:00 - huh, we've got 2012-03-12T16:31 UTC ?!
  • 2012GMT - 2012-03-12T20:12:00+00:00 - what's that ?!

tested just now at http://de.wikipedia.org/wiki/Spezial:Vorlagen_expandieren


Version: unspecified
Severity: normal

Details

Reference
bz35172

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:15 AM
bzimport added a project: ParserFunctions.
bzimport set Reference to bz35172.
bzimport added a subscriber: Unknown Object (MLST).

I'm not sure where the 7 is coming from, but ISO 8601 doesn't support the use of 'T' without at least specifying the hour (and negative times are not supported). Thus I'm inclined to make this bug as INVALID.

Side note: There is a related issue that PHP doesn't support the use of 'T' without both the hour and minute, but since you wrote...
2012-1T0 - <error>, OK
... I'm assuming that doesn't bother you. If it does, the PHP bug is https://bugs.php.net/bug.php?id=66019