Summary
DatePicker / Calendar can only represent a date. There is no way to pick or display a time of day, so applications that edit DATETIME / TIMESTAMP-like values have to hand-roll the time part and keep it in sync with CalendarState.
Environment
gpui-kit / gpui-component / gpui-base 0.6.1 (latest on crates.io as of 2026-09)gpui-pre 0.3.5- Windows (x86_64-pc-windows-gnu)
Current behavior / evidence
gpui_base::calendar::Date is Single(Option<NaiveDate>) | Range(Option<NaiveDate>, Option<NaiveDate>) — the controlled value is chrono::NaiveDate only.gpui_component::time only exposes calendar and date_picker; there is no TimePicker and no NaiveTime usage anywhere in the crate.DatePickerState::date_format defaults to "%Y/%m/%d"; there is no time format / precision option.
Use case
A database management GUI. When the user edits a MySQL DATETIME / TIMESTAMP cell, the picker must set YYYY-MM-DD HH:MM:SS. DatePicker can pick the day but not the time, and Calendar has no time affordance, so we currently compose Calendar with our own time spinner + validation.
Possible solutions (any one would unblock this)
- Add a standalone
TimePicker (hour / minute / second, 12/24h, stepper and/or text input) that apps can compose with the existing Calendar.
- Add optional time support to
DatePickerState — e.g. a NaiveDateTime-based Date variant, plus with_time / time_format / precision options and time columns in the popup.
- At minimum, document that the picker is date-only and that time is expected to be supplied by the app.
Note from the workaround
When composing Calendar inside an app-drawn popup, the calendar root uses track_focus, so a mouse-down moves focus to the calendar and blurs whatever input the app is editing (in our case an in-cell editor that commits on blur). We had to add capture_any_mouse_down(|_, window, _| window.prevent_default()) on the popup to keep focus in the editor. A future TimePicker would ideally not steal focus from its trigger by design.
Summary
DatePicker/Calendarcan only represent a date. There is no way to pick or display a time of day, so applications that editDATETIME/TIMESTAMP-like values have to hand-roll the time part and keep it in sync withCalendarState.Environment
gpui-kit/gpui-component/gpui-base0.6.1 (latest on crates.io as of 2026-09)gpui-pre0.3.5Current behavior / evidence
gpui_base::calendar::DateisSingle(Option<NaiveDate>) | Range(Option<NaiveDate>, Option<NaiveDate>)— the controlled value ischrono::NaiveDateonly.gpui_component::timeonly exposescalendaranddate_picker; there is noTimePickerand noNaiveTimeusage anywhere in the crate.DatePickerState::date_formatdefaults to"%Y/%m/%d"; there is no time format / precision option.Use case
A database management GUI. When the user edits a MySQL
DATETIME/TIMESTAMPcell, the picker must setYYYY-MM-DD HH:MM:SS.DatePickercan pick the day but not the time, andCalendarhas no time affordance, so we currently composeCalendarwith our own time spinner + validation.Possible solutions (any one would unblock this)
TimePicker(hour / minute / second, 12/24h, stepper and/or text input) that apps can compose with the existingCalendar.DatePickerState— e.g. aNaiveDateTime-basedDatevariant, pluswith_time/time_format/ precision options and time columns in the popup.Note from the workaround
When composing
Calendarinside an app-drawn popup, the calendar root usestrack_focus, so a mouse-down moves focus to the calendar and blurs whatever input the app is editing (in our case an in-cell editor that commits on blur). We had to addcapture_any_mouse_down(|_, window, _| window.prevent_default())on the popup to keep focus in the editor. A futureTimePickerwould ideally not steal focus from its trigger by design.