Last modified: 2012-10-19 08:00:43 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 T43126, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41126 - Some Julian dates are internally confused with Gregorian dates
Some Julian dates are internally confused with Gregorian dates
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Semantic MediaWiki (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Markus Krötzsch
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-17 19:01 UTC by ettore.callegari
Modified: 2012-10-19 08:00 UTC (History)
2 users (show)

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


Attachments

Description ettore.callegari 2012-10-17 19:01:41 UTC
if I #set the date 20 july 1283
when I #show the date, the date is not correct (13 luly 1283)


in this page http://wiki.isegretidelcarpione.it/index.php?title=Codice_Pelavicino_n._403
...
the source code is: {{#set:Data documento=20 lug 1283}}
...

in the preview, at the end of the page there is a box that shown the correct data:

	Fatti riguardanti Codice Pelavicino n. 403Feed RDF
	Data documento	20 luglio 1283
...
it is correct, but in this page: http://wiki.isegretidelcarpione.it/index.php?title=Cala
the source code is: {{#show:Codice Pelavicino n. 403|?Data documento}}
but the data shown is: 13 luglio 1283


what is strange is that this two pages list the page http://wiki.isegretidelcarpione.it/index.php?title=Codice_Pelavicino_n._403
the pages are:
http://wiki.isegretidelcarpione.it/index.php?title=Speciale%3ACercaPerPropriet%C3%A0&property=Data+documento&value=20+luglio+1283
http://wiki.isegretidelcarpione.it/index.php?title=Speciale%3ACercaPerPropriet%C3%A0&property=Data+documento&value=13+luglio+1283

I apologize for my english, Ettore
Comment 1 Markus Krötzsch 2012-10-18 09:13:16 UTC
Confirmed. The problem is cause by converting between different calendar models. Dates before 4 Oct 1584 are assumed to be in Julian calendar. SMW correctly recognises this here.

However, this information is not stored correctly. SMW currently assumes all stored dates to be in Gregorian calendar, but this conversion does not happen anywhere. So the Julian date gets stored without any indication that it is Julian. On reloading, SMW considers the date to be Gregorian, and converts it to Julian for display.

There are two ways in which we could fix this: (1) convert all dates to Gregorian before storing them or (2) store the calendar model with each date. The former would be easier, but it could create problems with conversion precision.

We may also need a better way to show if a date is Gregorian or Julian. But we do not want to write "Gr" or "Jl" next to every date. Suggestions are welcome.
Comment 2 Markus Krötzsch 2012-10-19 08:00:43 UTC
Fixed in https://gerrit.wikimedia.org/r/#/c/28666/ for SQLStore3. This change affects the way that data is stored in the database, so it is necessary to refresh the data to get the dates back. Dates stored in the old format will no longer be accessible.

The change also adds support for new output formats "Gr" and "Jl" that can be used in #ask to define the desired calendar model that should be displayed. The same strings also work as modifiers when writing dates. If nothing is given, SMW will assume the same default calendar model on input and on output. The new output formats do not depend on whether you are using SQLStore2 or SQLStore3.

The original problem will not be fixed for SQLStore2, which is supposed to be replaced by SQLStore3 on the next release (it will remain available for the next version but it will not get improvements/bugfixes).

(In general, there are still changes to come for SQLStore3 that may require rebuilding the database to upgrade.)

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


Navigation
Links