fix(timeformat): make datetime-local inputs honor the chosen time format - #744
Open
Giorgio-Germani wants to merge 2 commits into
Open
fix(timeformat): make datetime-local inputs honor the chosen time format#744Giorgio-Germani wants to merge 2 commits into
Giorgio-Germani wants to merge 2 commits into
Conversation
added 2 commits
August 28, 2026 09:52
Native datetime-local inputs (Forgot-to-end-workday modals, workday history corrections, contact/deal/lead activity forms) rendered in the browser locale (12h AM/PM on en-US) regardless of the user's or system's time format preference. They are now initialized as Flatpickr datetime pickers (new user-datetime-input class) that display in the resolved date + time format while submitting the same YYYY-MM-DDTHH:MM wire value; native min/max bounds move to the picker. Also route the recurring-tasks last-run cell and the admin version-update published timestamp through formatUserDateTime instead of raw toLocaleString, and add regression tests (one enforces that every datetime-local input in the app stays prefs-aware).
…main The branch CI failed on two issues that already exist on main, unrelated to the time-format fix: a trailing blank line at the end of app/routes/reports.py (flake8 W391) and four inline <script> tags without a CSP nonce (client portal quote detail, expense approvals, project health, utilization report). Repairs both so the pipeline is green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Native
<input type="datetime-local">fields (the "Forgot to end your workday?"workday modals, the workday history filter and inline correction rows, and the
contact/deal/lead activity forms) rendered their value in the browser locale
— e.g.
08/27/2026, 05:30 PMon an English (US) browser — regardless of thetime format the user or the system settings chose. This was the one remaining
surface in the app that ignored the 24h/12h preference, because the browser
controls the display format of native datetime inputs and JavaScript/CSS cannot
change it.
The app already had a Flatpickr-based pattern (
user-date-input/user-time-input) that displays pickers in the user's resolved date + timeformat while submitting unchanged wire values. This PR extends that pattern to
datetime-local inputs:
user-datetime-inputclass is picked up bydate-picker-init.jsandreplaced with a Flatpickr date-time picker (
time_24hrfollows the resolvedpreference, 24h by default). The submitted value stays
YYYY-MM-DDTHH:MM, sono backend changes are needed.
min/maxattributes (e.g. the auto-closed modal's latest-leave-timecap) are translated to Flatpickr
minDate/maxDateso the hidden wire inputcan't block form submission via browser constraint validation.
datetime-localinputs in the app are tagged with the new class: bothworkday modals, workday history, and the contact/deal/lead activity forms.
timestamp used raw
toLocaleString()(browser locale) and now go throughwindow.formatUserDateTime, which honors the preference.Type of change
Checklist
pytest).Related issues
Fixes # (no issue filed)