Add cross-platform DatePicker composable (commonMain)

[michaelabon]

Context

Per this comment, opening an issue so we can talk about the approach to add a cross-platform DatePicker composable in commonMain.

Two places currently use Android-only DatePickerDialog:

• MarkCompletedConstructionForm (construction quest opening date)
• DateTimeSelectField (log filtering screen)

Proposed approach

Two new files in commonMain, then wiring the component into both call sites above.

1. DateFormatElements.kt (util/locale/)

Locale-aware detection of date component ordering (DMY, MDY, YMD) and separator character, following the same approach as TimeFormatElements.kt. Formats a known reference date with the locale's short date formatter, then finds the positions of year, month, and day in the output to determine order.

2. DatePicker.kt (ui/common/)

A DatePicker composable using three WheelPickers (year, month, day), ordered according to the locale's DateFormatElements. Month wheel shows localized abbreviated month names.

State exposed via DatePickerState with a date: LocalDate property, created through rememberDatePickerState(initialDate, years).

Day clamping when month/year changes

The WheelPicker's items list is passed directly to a LazyColumn, so if the day list shrinks (e.g. 31 → 28) while day 31 is selected, the DatePicker must handle this explicitly.

The plan is to follow the convention used by both iOS UIDatePicker and Android's DatePicker (spinner mode):

• The day list updates immediately as the month wheel scrolls (not waiting for it to settle).
• If the selected day exceeds the new month's max, the day wheel animates to the new last day (e.g. 31 → 28 for February).
• The original day is not restored if you scroll back to a month that supports it.

Both platform pickers work this way (AOSP's DatePickerSpinnerDelegate recalculates maxValue on change; iOS's UIDatePicker clamps identically). This avoids invalid intermediate states where the user could see or submit "February 31".

In terms of implementation, a LaunchedEffect on month + year would call animateScrollToItem on the day WheelPickerState whenever the day count shrinks below the currently selected day.

Wiring it in

The PR would replace the Android DatePickerDialog in both MarkCompletedConstructionForm and DateTimeSelectField so we can verify the component works end-to-end. I'll include before/after screenshots in the PR.

As always, I'm happy for any feedback, edits, or pushback you may have on this approach!

[westnordost]

MarkCompletedConstructionForm

Oh! Good catch! No need to migrate that one yet, though. It makes sense to rewire at the same time when I do #5616 (comment)

Locale-aware detection of date component ordering (DMY, MDY, YMD) and separator character, following the same approach as TimeFormatElements.kt

Ah, also good catch, I didn't think about it. Yes, that makes sense. The month part (M) should be displayed as (short) month names, so that there will be no confusion what is day and what is month. I for example frequently use English, but I am not used to the (US) date format order.

The rest also sounds good!

In the end, you also need to add a DatePickerDialog composable (or DateSelectDialog), analogous to the dialog around the TimePicker.

Do you, by the way, use an AI to assist with your PRs? If yes, which one?

[michaelabon]

No need to migrate that one yet, though

Okay, no worries! I'll leave that one alone for now.

Do you, by the way, use an AI to assist with your PRs? If yes, which one?

No, I work for a company that is fully distributed, meaning that we haven't had "an office" for over 20 years, and everyone works very asynchronously. (I really like it as a way to work and I've been there since the start of the pandemic in 2020.)

So, you end up writing a lot, and sending people lots of context, to avoid a back-and-forth multi-day conversation. It can come across like AI-written text sometimes just because I'm trying to be thorough. When it comes to coding, I look at commit messages and pull requests as the indelible memory of the project, so I try to include the "why" I made a change, not just the "what" or the "how", because I'm not going to remember that in two weeks much less two years. So again, they tend to be more verbose. I can adjust my style if it's too much.

[westnordost]

No, I work for a company that is fully distributed, meaning that we haven't had "an office" for over 20 years, and everyone works very asynchronously. (I really like it as a way to work and I've been there since the start of the pandemic in 2020.)

OK, then the (good) AIs learned from (likes of) you, haha. I find your approach very professional and considerate. You obviously thoroughly research the topic before you get going 👍

[westnordost]

The month part (M) should be displayed as (short) month names, so that there will be no confusion what is day and what is month. I for example frequently use English, but I am not used to the (US) date format order.

Oh, while we are thinking about all nooks and crannies beforehand:

Some operating systems allow the user to actually set a different default date format in the settings. E.g. iOS does. Android apparently doesn't, yet (there is an issue for that).

I don't think that it is necessary to respect that setting, but if you would like to, you can use the same approach as done for actual/expect systemDefaultPrimaryMeasure(), given whether an API on iOS to query that setting exists. (I don't know, that's why the iOS implementation of that function is also empty).

But, well, if we start to respect this setting, probably there would even be more work to do, as the LocalDateFormatter currently also does not respect that setting. Unless NSCalendar already takes into account that setting internally, in which case there's actually nothing we need to do to make it respect the user's setting. (🎉)

[HolgerJeromin]

Do you, by the way, use an AI to assist with your PRs? If yes, which one?

Just a note: In my company we mostly use Claude Opus 4.6 for C++, C# and TypeScript coding.
It is a few weeks old and much better than older models (Claude <= 4.5 and at least GPT <= 5.3).

[westnordost]

Resolved

It looks like there is no explicit API for that on iOS, instead, dates formatted with NSCalendar etc. will automatically be formatted in the format the user set. As it should be. 👍