make #time work with pre-1970 dates
Closed, ResolvedPublic

Description

{{#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.


Version: unspecified
Severity: enhancement
URL: http://hu.wikipedia.org/wiki/User:Tgr/time

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz11686.
Tgr created this task.Via LegacyOct 16 2007, 11:41 PM
AzaToth added a comment.Via ConduitOct 17 2007, 12:39 AM

The only thing you can practically do before 1901 is calendar conversions of dates, see http://se2.php.net/manual/en/ref.calendar.php

brion added a comment.Via ConduitMar 17 2008, 10:06 PM
  • Bug 13374 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitOct 7 2008, 8:01 PM

rememberthedot wrote:

Has there been any progress on this? Expanding #time to work for at least all Gregorian (post-1582) dates would be really helpful.

bzimport added a comment.Via ConduitOct 7 2008, 8:17 PM

nsk wrote:

I think this works ok in en:

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

http://en.wikipedia.org/w/index.php?title=Template:Cite_web&action=edit

bzimport added a comment.Via ConduitOct 7 2008, 9:29 PM

rememberthedot wrote:

What do you mean? #time definitely does not work for pre-1970 dates on the English Wikipedia.

bzimport added a comment.Via ConduitOct 8 2008, 6:34 AM

rememberthedot wrote:

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?

attachment patch ignored as obsolete

bzimport added a comment.Via ConduitOct 9 2008, 7:11 PM

rememberthedot wrote:

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.

Attached: patch

brion added a comment.Via ConduitOct 9 2008, 7:27 PM

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).

brion added a comment.Via ConduitOct 9 2008, 7:31 PM

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. :)

bzimport added a comment.Via ConduitOct 9 2008, 7:49 PM

rememberthedot wrote:

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.

brion added a comment.Via ConduitOct 9 2008, 9:26 PM

date_create is listed as being introduced in 5.1.0 -- http://us3.php.net/date_create

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!)

brion added a comment.Via ConduitOct 9 2008, 9:30 PM

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.

bzimport added a comment.Via ConduitOct 10 2008, 7:16 PM

rememberthedot wrote:

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?

Attached: patch2

brion added a comment.Via ConduitOct 27 2008, 5:58 PM

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

bzimport added a comment.Via ConduitOct 27 2008, 7:32 PM

rememberthedot wrote:

Thank you!

Nikerabbit added a comment.Via ConduitFeb 4 2009, 7:43 AM
  • Bug 17346 has been marked as a duplicate of this bug. ***
Nikerabbit added a comment.Via ConduitFeb 28 2009, 7:50 PM
  • Bug 11929 has been marked as a duplicate of this bug. ***

Add Comment