Last modified: 2013-11-02 00:35:09 UTC
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
Confirmed: https://en.wikipedia.org/wiki/User:MarkAHershberger/Bug35172
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
