Fix date parsing

14319
Reporter: trobertson
Assignee: cgendreau
Type: Feedback
Summary:  Fix date parsing
Priority: Major
Status: Open
Created: 2013-10-31 10:10:34.126
Updated: 2016-02-05 16:24:07.784
        
Description: 

From the diatom image Tim created, and from JOT's previous analysis:

"Exactly! Tim, the example you showed reflects exactly what we found in
2009. The message from the publisher shows 00-00 as month-day, and the
parsed record (even verbatim) shows nov-30. We found this by comparing
provider messages against processed occurrence_date, and it was
consistent for almost all 00-00 and 00-XX (month=0).

The parser understands 0 in the month as the last month of the
previous year, and 0 in the day as the last day of the previous month,
in that order. So a 1812-00-00 (as shown in the original message) is
first interpreted as 1811-12-00 (last month of previous year) and then
as 1811-11-30 (last day of previous month). That dense line in Nov-30
is actually formed by records with 00-00. If you check the original
message and the raw and processed record, original year is 1812 and
processed year is 1811. That is what gave us the clue."]]>
    

Attachment output_image.png

Author: trobertson@gbif.org
Comment: Image shows the days of the year, each circle is a year, days start at 3 o'clock and increase clockwise.  November 30th has a strong signal which is noise.
Created: 2013-10-31 10:11:50.766
Updated: 2013-10-31 10:11:50.766

Author: trobertson@gbif.org
Comment: More here: https://journals.ku.edu/index.php/jbi/article/view/4125
Created: 2013-10-31 10:12:14.938
Updated: 2013-10-31 10:12:14.938

Author: trobertson@gbif.org
Created: 2013-10-31 10:12:24.722
Updated: 2013-10-31 10:12:24.722
        
And that, Arturo, relates to the two-line density of month lines. One
of the lines is Month-01, the other line is Month-00 which becomes
(Month-1)-(28/29/30/31)