Add non-throwing LocalDate(Time) construction & parsing about kotlinx-datetime HOT 4 OPEN

orNull variants of TimeZone.of or Something.parse probably make sense and follow the spirit of the provided link, which describes orNull as a modifier that shows that error conditions are expected (for example, when validating user input) and must be handled.

However, why is this needed for LocalDate? Could you please describe some situations where a programmer has values for year, month, and day, then puts these values into a LocalDate constructor, which rejects them, but this error is not a logic error and can somehow be recovered from?

from kotlinx-datetime.

from kotlinx-datetime.

Wouldn't one want the users to know what field did they make a mistake in? null does not say much, so custom logic would be needed anyway to show a helpful error.

Better yet, why not give the users a date picker that prevents invalid dates altogether?

from kotlinx-datetime.

Wouldn't one want the users to know what field did they make a mistake in? null does not say much, so custom logic would be needed anyway to show a helpful error.

Better yet, why not give the users a date picker that prevents invalid dates altogether?

Long-term? Probably. It's more work and probably pointless.
Short-term to get a project started in a fast & pragmatic way? No.
Also, if you rely on the browser's own date picker (HTML5 date input) some browsers may not support that. So users enter the date manually. Still needs to be checked.
Also, people understand e.g. "Your date of birth looks incorrect." just fine. There's not that much that can be wrong in a date.

I found more use-cases in my code where I use LocalDateOrNull:

• custom date picker implementation (K/JS)
• parse date from CSV import
• parse date from custom identifier that contains a date
• GraphQL date input parsing (needs custom error message, e.g. LocalDateOrNull(y,m,d) ?: graphError("message"))

from kotlinx-datetime.