Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

jiff: Days in month rangeint should always have range 28-31 #85

Merged
merged 1 commit into from
Aug 8, 2024

Conversation

nakedible
Copy link
Contributor

@nakedible nakedible commented Aug 8, 2024

I noticed that the days_in_month function returns constant rangeints where the range of the value is just the exact value, so for example v: 31, min: 31, max: 31. If the idea of the tracked min and max values (in debug builds) is to ensure that the code will work with all possible values of the function in question, then this means we don't actually check the computation for all possible responses to days_in_month.

By changing the return values to always have a range with min 28 and max 31 we can ensure that all calculations will work with every month and year, instead of the specific one they are tested with.

A sidenote is that if one returns just a common Day value from days_in_month, which has min of 1 and max of 31, this will end up throwing an error from the nth_weekday_in_month tests, as the algorithms there only stay in the correct range if the values returned by days_in_month are actually what they are commonly.

Not sure if I've figured out the situation correctly here – so feel free to just close this pull if it's a mistake.

And to be clear to anybody reading this – the changes here only affect debug builds and the internal safety checks in jiff. There are no external effects to these changes.

Copy link
Owner

@BurntSushi BurntSushi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good catch. I do believe this is indeed correct! Or at least, more correct than the status quo.

I suppose the fully correct version of this would actually utilize the computed min/max values on month to determine the range of days. Like, if Month has a value of 7 with a min/max also equal to 7, then returning a Day whose value, min and max are all 7 is correct. But I suspect that sort of thing doesn't happen in practice. And this patch is stricter than that, so if things are fine with these ranges then that should be okay overall even if it isn't as precise as possible.

@BurntSushi BurntSushi merged commit 224eee9 into BurntSushi:master Aug 8, 2024
17 checks passed
@nakedible nakedible deleted the days-in-month-range branch August 8, 2024 19:00
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants