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.
[Bug]: Custom snooze time picker ignores the Time format setting#19930
Before submitting
- I searched existing issues and did not find a dedicated duplicate. The related PR #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: https://github.com/pingdotgg/t3code/pull/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.
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.