Page MenuHomePhabricator

sprintftime aka #time can't handle timezones
Open, LowPublic

Description

Author: sebmol

Description:
I submit the two additional modifiers "L" (determines, if a year is a leap year)
and "W" (determines the day of the week as a number according to ISO-8601) as
described at http://www.php.net/date.

Index: Language.php
===================================================================
--- Language.php	(revision 16223)
+++ Language.php	(working copy)
@@ -474,9 +474,16 @@
 				case 'D':
 					$s .= $this->getWeekdayAbbreviation( self::calculateWeekday( $ts ) );
 					break;
+				case 'W':
+					$s .= self::calculateWeekday( $ts ) - 1;
+					break;
 				case 'j':
 					$num = intval( substr( $ts, 6, 2 ) );
 					break;
+				case 'L':
+					if (date( 'L', wfTimestamp( TS_UNIX, $ts ) ))
+						$s .= "1";
+					break;
 				case 'l':
 					$s .= $this->getWeekdayName( self::calculateWeekday( $ts ) );
 					break;

Details

Reference
bz7133

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:23 PM
bzimport added a project: ParserFunctions.
bzimport set Reference to bz7133.
bzimport added a subscriber: Unknown Object (MLST).

sebmol wrote:

That should be a lowercase 'w', the uppercase means something different. My
apologies. Here the updated patch:

Index: Language.php

  • Language.php (revision 16223)

+++ Language.php (working copy)
@@ -474,9 +474,16 @@
case 'D':
$s .= $this->getWeekdayAbbreviation( self::calculateWeekday( $ts ) );
break;
+ case 'w':
+ $s .= self::calculateWeekday( $ts ) - 1;
+ break;
case 'j':
$num = intval( substr( $ts, 6, 2 ) );
break;
+ case 'L':
+ if (date( 'L', wfTimestamp( TS_UNIX, $ts ) ))
+ $s .= "1";
+ break;
case 'l':
$s .= $this->getWeekdayName( self::calculateWeekday( $ts ) );
break;

sebmol wrote:

As of PHP 5.1.0, 'N' is used for ISO-compliant day-of-week calculation so I've
added it too:

Index: Language.php

  • Language.php (revision 16223)

+++ Language.php (working copy)
@@ -474,9 +474,19 @@

				case 'D':
					$s .= $this->getWeekdayAbbreviation( self::calculateWeekday( $ts ) );
					break;

+ case 'w':
+ $s .= date( 'w', wfTimestamp( TS_UNIX, $ts ) );
+ break;
+ case 'N':
+ $s .= date( 'N', wfTimestamp( TS_UNIX, $ts ) );
+ break;

				case 'j':
					$num = intval( substr( $ts, 6, 2 ) );
					break;

+ case 'L':
+ if (date( 'L', wfTimestamp( TS_UNIX, $ts ) ))
+ $s .= "1";
+ break;

				case 'l':
					$s .= $this->getWeekdayName( self::calculateWeekday( $ts ) );
					break;

Can we add "z", "W" and "t", please? At least "t" would be very practical. Thanks.

ayg wrote:

Patch to add all date() key letters

No reason not to add all of them. For a number I've just called date(), as
Sebastian did, because there's no other way to get stuff like day of the week
or RFC 2822 format from the timestamp in a few lines.

This patch does not work correctly, because I don't understand how
timezones work in MediaWiki. Anything that calls date() returns times/dates
based on my local timezone, while the actual timestamp passed is UTC. This
needs to be corrected by someone who knows how timezones work in MediaWiki. It
should be pretty easy, but I haven't figured out exactly how internal date
storage works yet.

Note that SaAe should be internationalized. Also note that since the
timestamps will always have the same time zone (right?), eOPTZ (and maybe I)
could possibly benefit quite a bit from memoization.

Attached:

ayg wrote:

(ParserFunctions should be in the component list . . .)

sebmol wrote:

The timezone is usually that of the server. So if you tested your code own your
own MediaWiki installation, you will get the appropriate timezone. Wikimedia
servers run on UTC (I think). You should take a look in Language.php to see how
the new variables LOCALHOUR, LOCALDATE, etc. are implemented to get an idea of
what is necessary to work with different time zones.

sebmol wrote:

local specifier to work with local timezone

I've added another patch, that allows for local (i.e. timezone dependent) time
calculations by adding a new time specifier "local", e.g.
{{#time:Ymdhis|local}} creates a MW timestamp for the current local time and
date.

Attached:

baard wrote:

When using the {{#timel:}} function to display formatted time, it shows the time in whatever timezone the server is configured to use. But there is no way to display the timezone for the time shown. This is important when one is in DST and the displayed time is normal time. So "e", "I" and "T" would be useful to avoid the confusion.

EN.WP.ST47 wrote:

Whoever fixes this should also fix bug 7986

a.d.bergi wrote:

(In reply to comment #8)

So "e", "I" and "T" would be useful to avoid the confusion.

The I parameter would be really useful. In the German Wikipedia we have the problem that there is a date (not yet, otherwise we could use {{LOCALDATE}}-{{CURRENTDATE}}) of which we want to the UTC time. {{#time:I|{{{date}}} }} should help to find out whether the {{{date}}} was in MESZ or MEZ (fixme?).

I propose this bug not to be an enhancement but of normal priority.

  • Bug 7986 has been marked as a duplicate of this bug. ***
  • Bug 15045 has been marked as a duplicate of this bug. ***

The problem here is that sprintfDate gets a adjusted timestamp and it knows nothing about the timezone. Thus we can't currently support format characters that output timezone or any other which need to know the timezone.

  • Bug 28353 has been marked as a duplicate of this bug. ***

audreyt wrote:

Hi Sebastian & Aryeh, thank you for the patch!

As you may already know, MediaWiki is currently revamping its PHP-based parser
into a "Parsoid" prototype component, to support the rich-text Visual Editor
project:

https://www.mediawiki.org/wiki/Parsoid
https://www.mediawiki.org/wiki/Visual_editor

Folks interested in enhancing the parser's capabilities are very much welcome
to join the Parsoid project, and contribute patches as Git branches:

https://www.mediawiki.org/wiki/Git/Tutorial#How_to_submit_a_patch

Compared to .diff attachments in Bugzilla tickets, Git branches are much easier
for us to review, refine and merge features together.

Each change set has a distinct URL generated by the "git review" tool, which
can be referenced in Bugzilla by pasting its gerrit.wikimedia.org URL as a
comment.

If you run into any issues with the patch process, please feel free to ask on
irc.freenode.net #wikimedia-dev and the wikitext-l mailing list. Thank you!

  • Bug 13357 has been marked as a duplicate of this bug. ***