Repository navigation
[Bug]: Custom snooze time picker ignores the Time format setting #19930
Description
Before submitting
- I searched existing issues and did not find a dedicated duplicate. The related PR fix(web): style custom snooze time picker like the calendar #12440 was closed without merging.
Area
apps/web / apps/desktop
Steps to reproduce
- In Settings → Time format, select 24-hour.
- Open a thread's Snooze → Custom → Date and time dialog.
- Open the time picker.
Expected behavior
The time picker respects the configured time format:
- 24-hour:
17:30 - 12-hour:
5:30 PM - System default: use the user's system locale.
Actual behavior
The time picker displays a 12-hour AM/PM interface even when the 24-hour format is selected in T3 Code settings.
Additional context
apps/web/src/components/CustomSnoozeDialog.tsx currently uses a native input type="time". Its displayed hour format is controlled by the browser/Electron environment, rather than T3 Code's Time format setting.
PR #12440 previously addressed both time picker styling and respecting the configured 12/24-hour format, but was closed without merging: #12440
The behavior was independently confirmed in a comment on that PR, with 24-hour format explicitly selected.
A full custom picker redesign isn't necessary to resolve this report. The main requirement is that the picker honors the user's chosen time format.
Activity
juliusmarminge commentedon Oct 21, 2026
Reproduced in the real web app on main 70e5e384da: Chrome on Linux, en-US, isolated seeded thread data. Selected Settings → Time format → 24-hour, then Snooze → Custom → Date and time. The preset menu showed 23:35; the custom field showed 11:35 PM. With 12-hour selected, the same field also showed AM/PM. The stored time value remained 23:35.
juliusmarminge commentedon Oct 22, 2026
Opened #23518 for the reproduced web bug. On 9c662e5b6c, the custom picker follows 24-hour, 12-hour and System default settings; the existing snooze tests pass 11/11. Before/after evidence and verified keyboard recordings cover Chrome/Linux at desktop and narrow widths in both themes. Electron and baseline native-popup motion remain unverified.
vpsman commentedon Nov 9, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of vpsman
Also hitting this in the desktop (Electron) app, v0.1.8-nightly.20261109.4433 on Linux, which the #23518 testing didn't cover (Chrome/Linux only). With Time format → 24-hour, Snooze → Custom → Date and time still shows a 12-hour field with an AM/PM selector. Besides not matching the setting, it's clunky to use: you have to tab across to the AM/PM part to enter an afternoon time.
The code on current
main(ff7aa5a) is unchanged, and #23518 looks stalled. It now conflicts withmainand hasn't been updated since Oct 22. It also only changesCustomSnoozeDialog.tsx. The same browser-native<input type="time">is inSnoozePresetsSettings.tsxandScheduledTasksSettings.tsx(#27233). One time input that follows the setting, used in all three places, would close both issues.