Last modified: 2014-05-01 23:40:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T32148, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 30148 - Year 10,000 problem
Year 10,000 problem
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.23.0
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-31 08:58 UTC by anminh2008
Modified: 2014-05-01 23:40 UTC (History)
10 users (show)

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


Attachments

Description anminh2008 2011-07-31 08:58:43 UTC
The MediaWiki software does not supprt 5+ digits year, make it vulnerable to the http://en.wikipedia.org/wiki/Year_10,000_problem and year 10^n (where n is a natural number) problem
Comment 1 p858snake 2011-07-31 09:07:19 UTC
Bumping back down, not a blocker... This isn't really a issue, This can be fixed in a "few" years closer to event if its a issue then.
Comment 2 anminh2008 2011-08-01 07:24:22 UTC
Fix it before it is too late to fix!!! FIX ONCE FOR FOREVER!!!!!!!!!
Comment 3 p858snake 2011-08-01 07:26:24 UTC
WONTFIXing this, we will most likley not do this, or if we do it won't be for ages since their isn't a pressing need for it.


But if you do desire feel free to work on it and send us patches for it.
Comment 4 anminh2008 2011-08-01 07:41:16 UTC
Are you ad your succesors choose to not fix it even after the Dark Era!?
Comment 5 Chad H. 2011-08-01 16:18:47 UTC
We can reopen this sometime around the 10th millennium.
Comment 6 anminh2008 2011-08-02 01:17:44 UTC
If your math formulas involve future times, like astronomical calculation, you MUST fix it right now.
Comment 7 Chad H. 2011-08-02 01:21:39 UTC
Well now you're talking about different things...which sort of failures are you talking about? Stuff involving math operations on dates probably is a ParserFunction bug. Problems with date autolinking are MW core, but we're not expanding that to non-English and might even remove it from English too making it a non-bug. Stuff relating to tracking of revision timestamps and the like won't be an issue for ~8000 more years.
Comment 8 Ori Livneh 2014-02-01 17:57:24 UTC
Causing exceptions in production.

Example: <https://en.wikipedia.org/wiki/Special:FeedItem/featured/2014021000000/en>

2014-02-01 17:38:26 mw1036 enwiki: [2ec80205] /wiki/Special:FeedItem/featured/2014021000000/en   Exception from line 1131 of /usr/local/apache/common-local/php-1.23wmf11/languages/Language.php: Language::sprintfDate: The timestamp 657911014000000 should have 14 characters
#0 /usr/local/apache/common-local/php-1.23wmf11/languages/Language.php(2045): Language->sprintfDate('j F Y', '657911014000000')
#1 /usr/local/apache/common-local/php-1.23wmf11/extensions/FeaturedFeeds/SpecialFeedItem.php(52): Language->date(2014020979200)
#2 /usr/local/apache/common-local/php-1.23wmf11/includes/specialpage/SpecialPage.php(374): SpecialFeedItem->execute('featured/201402...')
#3 /usr/local/apache/common-local/php-1.23wmf11/includes/SpecialPageFactory.php(487): SpecialPage->run('featured/201402...')
#4 /usr/local/apache/common-local/php-1.23wmf11/includes/Wiki.php(298): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#5 /usr/local/apache/common-local/php-1.23wmf11/includes/Wiki.php(599): MediaWiki->performRequest()
#6 /usr/local/apache/common-local/php-1.23wmf11/includes/Wiki.php(460): MediaWiki->main()
#7 /usr/local/apache/common-local/php-1.23wmf11/index.php(49): MediaWiki->run()
#8 /usr/local/apache/common-local/w/index.php(3): require('/usr/local/apac...')
#9 {main}

Language::date depends on Language::sprintfDate, which does not support TS_MW values longer than 15 characters, but MWTimestamp::getTimestamp( TS_MW ) is liable to generate 15-character values.

> $ts = wfTimestamp( TS_MW, 253402300800 )
> $wgContLang->date( $ts );
[b4a5f86b] [no req]   Exception from line 1131 of /a/common/php-1.23wmf11/languages/Language.php: Language::sprintfDate: The timestamp  should have 14 characters
Backtrace:
#0 /a/common/php-1.23wmf11/languages/Language.php(2045): Language->sprintfDate(string, boolean)
#1 /a/common/php-1.23wmf11/maintenance/eval.php(71) : eval()'d code(1): Language->date(string)
#2 /a/common/php-1.23wmf11/maintenance/eval.php(71): eval()
#3 /a/common/multiversion/MWScript.php(97): require_once(string)
#4 {main}

The immediate fix for FeaturedFeeds is to reject feed timestamps set so far in the future as invalid.

The longer-term fix is to make the handling of >14 character timestamps consistent across MWTimestamp and Language::sprintfDate, either by making MWTimestamp decline to represent dates beyond 10000-01-01 using TS_MW format, or by making Language::sprintfDate handle TS_MW values longer than 14 characters.
Comment 9 Ori Livneh 2014-02-01 20:21:36 UTC
(In reply to comment #8)
> <https://en.wikipedia.org/wiki/Special:FeedItem/featured/2014021000000/en>
> The immediate fix for FeaturedFeeds is to reject feed timestamps set so far
> in the future as invalid.

(Done in Gerrit change I8a600d37a.)
Comment 10 Niklas Laxström 2014-02-03 16:26:34 UTC
As for handling these in sprintfDate, I'm reluctant to make any changes until PHP's DateTime also supports years > 9999 because we could only provide partial support without that.
Comment 11 gnosygnu 2014-04-18 04:51:33 UTC
I just wanted to add a few points that may be of interest to someone.

(1) This error may become more common with wikidata and its time datatype. I was looking at some errors in XOWA log files for ca.wikipedia.org and discovered that Saint Nicholas (https://ca.wikipedia.org/wiki/Nicolau_de_Mira) shows up as having died in 2003. See https://ca.wikipedia.org/wiki/Categoria:Morts_el_2003 . He died in 343 A.D..

For those interested, here's the process:

* https://ca.wikipedia.org/wiki/Nicolau_de_Mira calls {{Sant}}
* {{Categoria per any de defunció}} is called
* {{#invoke:Wikidata|formatStatements|property=P570|formatting=year}} is called
* www.wikidata.org/wiki/q44269 defines P570 (year of death) as
+000000000343-12-06T00:00:00Z
* Note that this date adds an extra 0 at the beginning. Presumably this is a bug related to dates with a year < 1000.
* This differs from other recent years of death 
: For example, Albert Einstein (www.wikidata.org/wiki/q937) has this as his P570
+00000001955-04-18T00:00:00Z
* Module:Wikidata calls lang:formatDate("Y", string.sub(d, 9, 18))
: This effectively becomes {{#time:Y|00343-12-0}} which generates 2003 (see note (2) below for more info)
* The end result is Nicolau_de_Mira is listed as dying in year 2003: https://ca.wikipedia.org/wiki/Categoria:Morts_el_2003

(2) Any 5 digit year appears to produce a 4 digit year using the following method: "200" + 5th digit

=== 5 digit years ===
{{#time:Y-m-d|00002-4-5}}<br/>  -> 2002
{{#time:Y-m-d|54321-4-5}}<br/>  -> 2001
{{#time:Y-m-d|12345-4-5}}<br/>  -> 2005
{{#time:Y-m-d|55555-4-5}}<br/>  -> 2005

(3) 6+ digit years are basically random, depending on what the last 4 digits are. I've gotten these type of results: current year; "19"+last_2_digits; "200"+last_digit; random substrings in the string; invalid time

You can start with these examples, and then try reversing them, or inputting random numbers

=== 6-14 digit years
{{#time:Y-m-d|12345-4-5}}<br/>       
{{#time:Y-m-d|123456-4-5}}<br/>      
{{#time:Y-m-d|1234567-4-5}}<br/>     
{{#time:Y-m-d|12345678-4-5}}<br/>    
{{#time:Y-m-d|123456789-4-5}}<br/>   
{{#time:Y-m-d|1234567890-4-5}}<br/>  
{{#time:Y-m-d|12345678901-4-5}}<br/> 
{{#time:Y-m-d|123456789012-4-5}}<br/>
{{#time:Y-m-d|1234567890123-4-5}}<br/>
{{#time:Y-m-d|12345678901234-4-5}}<br/>
Comment 12 gnosygnu 2014-04-18 04:56:45 UTC
As a separate note, I've filed https://bugzilla.wikimedia.org/show_bug.cgi?id=64084 for the Wikidata issue

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


Navigation
Links