Last modified: 2014-11-18 18:07:26 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11686 - make #time work with pre-1970 dates
make #time work with pre-1970 dates
Product: MediaWiki extensions
Classification: Unclassified
ParserFunctions (Other open bugs)
All All
: Normal enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 11929 13374 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2007-10-16 23:41 UTC by Tisza Gergő
Modified: 2014-11-18 18:07 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Proposed patch (1.98 KB, patch)
2008-10-08 06:34 UTC, rememberthedot
Proposed patch v2 (1.89 KB, patch)
2008-10-09 19:11 UTC, rememberthedot
Proposed patch v3 (2.90 KB, patch)
2008-10-10 19:16 UTC, rememberthedot

Description Tisza Gergő 2007-10-16 23:41:36 UTC
{{#time}}, being based on the PHP function strtotime(), does not work with dates before 1970-01-01 (or dates before 1901-12-13, depending on the PHP version). In the absence of string manipulation functions, #time is the only way to make templates which are intuitive to use and still look nice. (For example, some citation templates need the date both in text format for display, and in number format for metadata.) Please extend it to dates before the Unix epoch.
Comment 1 Carl Fürstenberg 2007-10-17 00:39:50 UTC
The only thing you can practically do before 1901 is calendar conversions of dates, see
Comment 2 Brion Vibber 2008-03-17 22:06:33 UTC
*** Bug 13374 has been marked as a duplicate of this bug. ***
Comment 3 rememberthedot 2008-10-07 20:01:44 UTC
Has there been any progress on this? Expanding #time to work for at least all Gregorian (post-1582) dates would be really helpful.
Comment 4 NSK Nikolaos S. Karastathis 2008-10-07 20:17:11 UTC
I think this works ok in en:

check the corresponding template in en: to see whether it has any changes:

Comment 5 rememberthedot 2008-10-07 21:29:59 UTC
What do you mean? #time definitely does not work for pre-1970 dates on the English Wikipedia.
Comment 6 rememberthedot 2008-10-08 06:34:05 UTC
Created attachment 5399 [details]
Proposed patch

I've coded up a patch which makes #time use PHP's DateTime object instead of strtodate. It looks like this works fine for all dates. It also avoids switching environment variables back and forth, which is generally not a good idea because another application may get an improper value for the variable while it is being switched in and out.

I tested the patch and it appears to behave identically to the current version of ParserFunctions, except without the 1970 and 2038 date barriers. Please feel free to test it more to your heart's content.

One issue: I am a bit confused about how $wgLocaltimezone comes into play. DefaultSettings.php states:

 * This variable is currently used ONLY for signature formatting, not for
 * anything else.

So, I'm a bit confused about what $wgLocaltimezone is doing in ParserFunctions.php. Does the comment mean that $wgLocaltimezone is not supposed to be used in extensions?
Comment 7 rememberthedot 2008-10-09 19:11:03 UTC
Created attachment 5410 [details]
Proposed patch v2

I'm submitting a revised patch for this bug - the new patch works exactly the same as the old one, but uses simpler code. It turns out that I didn't have to explicitly get PHP's default time zone and then pass that to the DateTime constructor; PHP does all that automatically.
Comment 8 Brion Vibber 2008-10-09 19:27:26 UTC
The DateTime class is new in PHP 5.2; currently we have a minimum requirement of 5.0 (though we'll possibly bump that to 5.1 soon).

My impression is that the DateTime class is just a pretty wrapper on the date_* procedural functions introduced in 5.1... The most compatible thing might be to use the date_* functions (for 5.1 and 5.2) if they exist, and fall back to the old unix-based functions for 5.0 (in which case the pre-1970 dates don't work, but modern ones will be fine).
Comment 9 Brion Vibber 2008-10-09 19:31:05 UTC
As for $wgLocaltimezone... it seems that's only being used for when 'local' time formatting is explicitly requested, in which case it would match the formatting of timestamps for signatures. In theory. :)

$wgLocaltimezone, if set, overrides the system's generally-set local timezone; if not set, then whatever the server thinks is local time will be used. (Say, PST/PDT for a server in California, unless the server is configured on UTC. :)
Comment 10 rememberthedot 2008-10-09 19:49:18 UTC
Okay, I should be able to make it switch to the new implementation only if DateTime is available. I think date_create was introduced in the same version as DateTime, so there's not much point in using date_create instead. It seems that in PHP 5.1, DateTime and friends were included but not enabled by default.

While I'm willing to write more code to resolve this, it does seem like it would make more sense to just increase the ParserFunctions extension's PHP version requirement to 5.2. Wikimedia already uses 5.2, and really, it's just an extension, not part of the core functionality.
Comment 11 Brion Vibber 2008-10-09 21:26:57 UTC
date_create is listed as being introduced in 5.1.0 --

Lots of folks need to install ParserFunctions to make use of, for instance, fancy templates they get from Wikipedia, so we don't want to be needlessly exclusive of folks who are one minor version back. (A lot of hosting providers are probably running the 5.1.x-with-security-updates in their Linux distro. We only upgraded to 5.2 ourselves very recently!)
Comment 12 Brion Vibber 2008-10-09 21:30:02 UTC
Ugh, it also looks like the date functions might not even be compiled in on any given install, especially in 5.1. :D

Might be sanest to just fall back to strtotime() if DateTime doesn't exist, yeah.
Comment 13 rememberthedot 2008-10-10 19:16:29 UTC
Created attachment 5416 [details]
Proposed patch v3

All right, here is a new patch that uses DateTime if available, and falls back on strtotime if not. I tested both code branches and it looks like it works either way. Is there anything else that should be done before this patch can be integrated into MediaWiki?
Comment 14 Brion Vibber 2008-10-27 17:58:17 UTC
Looks good! Applied on r42663 with a minor tweak ('DateTime' wasn't quoted in the class check).

I added a couple quick parser test cases to confirm the behavior. This exposed an oddity (IMHO) which is that times are input with the local timezone that happens to be in place on the server, rather than anything that's been explicitly defined. But that's a problem for another bug. :D
Comment 15 rememberthedot 2008-10-27 19:32:47 UTC
Thank you!
Comment 16 Niklas Laxström 2009-02-04 07:43:48 UTC
*** Bug 17346 has been marked as a duplicate of this bug. ***
Comment 17 Niklas Laxström 2009-02-28 19:50:31 UTC
*** Bug 11929 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.