-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cal2dec not robust to leap years ! #35
Comments
I remember having this exact discussion with @kamwal before I had written any code at all! I then spoke to someone else, I cannot remember who, and was told it wasn't n issue, but I cannot remember who or why. Perhaps we should reopen investigations, and when I have the answer I can post it here |
I couldn't find the discussions we had, but @kamwal remembers that we decided to convert the code as is initially, and then look to change this in the future. So we can keep this task on here. |
@kamwal found the discussion: "It is true that leap years are not taken into account in the calculation of DATES (decimal year). OW uses DATES in decimal year to compute the time difference between the float date and the date of the reference data, that gives a "weight" to the reference data in the mapping procedure (The piece-wise linear fit does not uses DATES but N-CYCLE). So the above comment still stands: Not a pressing issue, but certainly something worth changing eventually. |
ok, the function above can be used to replace the old one |
The cal2dec function reads:
and the decimal year is then computed in
change_dates
with:But I'm not sure this function is robust to leap years.
For instance here we can find this implementation:
which takes the year into account, contrary to
cal2dec
.So the difference will read:
This may not be very significant for the calibration, but this is simply not right and we should fix this.
The text was updated successfully, but these errors were encountered: