We use PHP conversion function cal_to_jd( CAL_JULIAN, $m, $d, $y ); in https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/repo/includes/rdf/JulianDateTimeValueCleaner.php . Searching the bug tracker: https://www.google.com/search?q=julian+site:bugs.php.net reveals some reports that might warrant answering and adding more upstream (in the PHP project) phpt test cases.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T87764 Bugs related to time datatype (tracking) | |||
| Invalid | None | T106922 calendar conversion of dates | |||
| Declined | None | T106923 [Task] add phpt testcases to prove reports regarding bugs in PHP calendar conversion function for julian date and day |
Event Timeline
Comment Actions
There is a single call to the cal_to_jd function (followed by jdtogregorian) in Wikibase\Rdf\JulianDateTimeValueCleaner, which is currently exclusively used in RDF exports. It's backed up by some checks and returns null in case it could not convert a Julian date to Gregorian. This means a lot of valid Wikidata date values will not be in the RDF output, most notably B.C. values with DAY precision.
Is all this relevant for this task or is this about something else? Can you please list the "some reports" we should check?
Comment Actions
This means a lot of valid Wikidata date values will not be in the RDF output, most notably B.C. values with DAY precision.
That is not what this ticket is about. This ticket is about there being open bug reports about cal_to_jd in zend PHP doing wrong conversion.
Comment Actions
I don't have experience coding in PHP, it appears PHP is a loosely typed language that converts among integers and floating point numbers implicitly, with no way to even declare which type a variable is. Trying to calendar programming in such a language is tricky, particularly since calendar programming is full of integer division and modulo operations that depend on the exact behavior of these functions, including how they work with negative numbers.
My intuition is that many of the bug reports will be people feeding floats into functions only intended to use ints, or people who tried to predict the results with a desk calculator and didn't get the integer divisions right.
If JanZerebecki has identifed some bug reports that JanZerebecki thinks are valid, it might be useful to list them.
I have a widely respected book by Dershowitz & Reingold, Calendrical Calculations, which has tables giving examples of significant dates in several calendars, over a wide range of years. I would be happy to list some of these dates, and even test them in PHP. Is there any particular format that the test cases should be in?
(Sure, I've never used PHP, but I've been adding languages to my collection since the days of punched cards.)
Comment Actions
The format php upstream uses is called phpt. Thx for the reference to the book. I'm afraid this task is more my personal wish for being as exact as possible, while in reality there are many more important things to do that will give more benefit in terms of being more exact.
Comment Actions
The referenced https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/repo/includes/Rdf/JulianDateTimeValueCleaner.php was made much more robust since this ticket was created. Since it never listed specific issues I don't think there is anything we can or should do here.