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

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

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.

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

rememberthedot wrote:

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

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

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:

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

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

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.

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

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.

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:

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

rememberthedot wrote:

Thank you!

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

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