Skip to content

Conversation

dkhalanskyjb
Copy link
Contributor

From 0.4.0 on (dc5c965), we have LocalTime.atDate with the default value 0 for dayOfMonth: Int. This doesn't make any sense, though, as 0 is not a valid day, so LocalTime(23, 59).atDate(2025, 3) just fails. This commit removes the default value. Since it was impossible to call atDate without specifying the day and not fail, no valid code should stop compiling.

From 0.4.0 (dc5c965), we have
`LocalTime.atDate` with the default value `0` for
`dayOfMonth: Int`. This doesn't make any sense, though, as `0` is
not a valid day, so `LocalTime(23, 59).atDate(2025, 3)` just fails.
This commit removes the default value.
Since it was impossible to call `atDate` without specifying the
day and not fail, no valid code should stop compiling.
@dkhalanskyjb dkhalanskyjb requested a review from ilya-g March 18, 2025 13:52
@dkhalanskyjb dkhalanskyjb added this to the 0.7.0 milestone Mar 18, 2025
@dkhalanskyjb dkhalanskyjb merged commit 1833158 into master Mar 20, 2025
1 check passed
@dkhalanskyjb dkhalanskyjb deleted the fix-atDate branch March 20, 2025 15:13
dkhalanskyjb added a commit that referenced this pull request Mar 20, 2025
From 0.4.0 (dc5c965), we have
`LocalTime.atDate` with the default value `0` for
`dayOfMonth: Int`. This doesn't make any sense, though, as `0` is
not a valid day, so `LocalTime(23, 59).atDate(2025, 3)` just fails.
This commit removes the default value.
Since it was impossible to call `atDate` without specifying the
day and not fail, no valid code should stop compiling.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants