Date normalization strategy

[srishanbhattarai]

Collection of my thoughts around date normalization in Nepcal.

#79 reported a bug where a B.S. date that overflowed into the next month would not be rejected by Nepcal.

The provided example was 12-31-2076 which is to be considered invalid because the month of Chaitra does not contain 31 days, it only contains 30. The current behavior (although implicit) was that this date would overflow over to 01-01-2077, and any B.S. to A.D. conversions would use this value.

From the user's perspective: a) 01-01-2077 converts into April 13, 2020 Monday (so far so good!) b) 12-31-2076 ALSO converts into April 13, 2020 Monday because of the overflow.

This silent overflow behavior is also exhibited by Go's own time package - if you call time.Date with the date February 30 it will overflow to April, which is why I recall keeping the current behavior the way it is. We will use the same taxonomy for this behavior and call it normalization.

#80 proposes to change the current behavior by explicitly rejecting dates that would have normalized. My thoughts at this moment are the following:

a) Error-ing out seems the right decision here, instead of silent behavior the user may be unaware of. However, I don't want Hyrum's law to bite me if I change this, so this release should be a version bump at the minimum.

b) For B.S. dates, we typically work with raw "dd, mm, yy" values so it's easy to check for normalization. What do we do for A.D. dates i.e. the FromGregorian functions which directly take in a time.Time. Should nepcal also have guard rails against allowing normalization of A.D. dates? To be clear, this means breaking the FromGregorian API to ingest a "dd, mm, yy" triple similar to B.S. dates, explicity check if this date will normalize, and reject it. Again, Hyrum's law, and therefore version bump?