Support dates all the way to 1BC

[changhc]

This is my attempt to fix pydantic/pydantic#8570. Tested this locally with pydantic-core and it worked.

The reason of that original error is underflow. I'm not very sure what is so special about year 1600 and why that was introduced. It seems that it was once year 1000 in c7f9257 but somehow it was revert back to 1600. Considering @davidhewitt's comment #55 (review), since the minimum time string allowed in RFC 3339 is 0000-01-01T00:00:00+00:00 (UTC since other timestamp constants are also in UTC,) I think it makes sense to replace that year 1600 constant with the minimum year 0000, which will help get rid of the underflow problem.

I added some test cases for the minimum timestamp and other existing test cases still work, but I'm not sure if I missed out anything, especially because I still don't know why 1600 was used in the first place.

Note that now watershed does not cover the entire range of acceptable negative timestamp values. I changed that value to cover the entire range at first, but then I reverted the change since that would probably affect existing users relying on that value.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.87%. Comparing base (0ffbcbb) to head (8ec817d).
Report is 12 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #77      +/-   ##
==========================================
- Coverage   99.12%   98.87%   -0.26%     
==========================================
  Files           6        6              
  Lines         917      974      +57     
==========================================
+ Hits          909      963      +54     
- Misses          8       11       +3     

Files with missing lines	Coverage Δ
src/date.rs	100.00% <100.00%> (ø)
src/datetime.rs	100.00% <ø> (ø)
src/lib.rs	91.66% <ø> (ø)

... and 3 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 680566a...8ec817d. Read the comment docs.

[davidhewitt]

Thanks for working on this, this seems correct to me!

I assume that this will fix #15; can we please add some additional test cases around leap years to check that this is indeed the case?

[davidhewitt]

Can we restore these test cases? Not immediately clear to me why they were deleted.

[changhc]

I removed them because this test case is called date_from_timestamp_extremes and 1600 is no longer "an extreme value" (and I added 0000-01-01 instead.) I'll create a new test case and add them back.

[changhc]

I've added 3 cases checking 1 BC, 1200 AD and 1600 AD. Is there anything else specific I should add? I think other cases are already covered.

[davidhewitt]

It would be good to check February 29th of some leap years in that 0-1599 range to confirm we are handling them correctly.

From wikipedia

Every year that is exactly divisible by four is a leap year, except for years that are exactly divisible by 100, but these centurial years are leap years if they are exactly divisible by 400. For example, the years 1700, 1800, and 1900 are not leap years, but the year 2000 is.

So I guess February 29th should be valid on 1200, but not 1300, 1400, 1500.

Similarly we could check 1200 (yes), 1201 (no), 1202 (no), 1203 (yes).

[changhc]

I see. I've added some more test cases. Definitely not covering the entire range 0-1600 but I think these should be enough, unless we really want more of these tests.

[davidhewitt]

Perfect, this looks great to me! Thanks 🙏