Skip to content

Conversation

@dkhalanskyjb
Copy link
Collaborator

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.

3 participants