Date Picker Design

📅 Dates you type in, in your format - design (#355)

Related: Date and time formats (GH #105) · Timezones and time handling.

---

The problem

FreeITSM writes every date in the format chosen in System → Date and time formats (or the analyst's own, in Preferences): Sun 15 Nov 2026 10:00. But every box where a date or time is typed in - about 150 of them, in 22 parts of the app - is the browser's own date picker (<input type="date">, datetime-local, time). A web page cannot tell that picker how to write a date: it follows the browser's language and the computer's region. With a US-English browser, a Greek service desk that chose 05 Aug 2026 and the 24-hour clock still types into 11/15/2026 and 10:00 AM (#355, pappas81).

Workaround until this ships: set the browser's language (Chrome / Edge: Settings → Languages) to one that writes dates your way - Greek, or English (United Kingdom) - at the top of the list; on Windows the region does the same.

The shape

One script on every page (assets/js/date-input.js) upgrades every date, date-and-time and time box automatically - including boxes that appear later, in dialogs and lists - into FreeITSM's own picker:

• a text box showing the value in the chosen format (05 Aug 2026 14:30), which can also be typed into in that format;
• a small calendar to click, with month names in the interface language and weeks starting on the chosen day; a time list on the 24-hour or 12-hour clock as chosen.

The browser's own box stays underneath, hidden, and keeps holding the value exactly as now (2026-08-05, 2026-08-05T14:30, 14:30). So every existing screen that reads, saves or fills a date keeps working unchanged - no screen has to be rewritten, and nothing stored changes. When a date is picked, the hidden box gets it and fires the same input and change events it always did; when code fills the hidden box, the visible one follows.

Phones and tablets keep their own picker - the big native wheel or calendar people expect on a touch screen. Only mouse-and-keyboard screens are upgraded.

A box that must stay native can opt out with data-native-date.

Decisions

Put to Ed on 16 November 2026. His answers are what is built.

Question	Decision	Why
How to fix it	FreeITSM's own picker, following the format setting (option B) - not just the browser-language workaround, and not a second formatted date beside each box	The setting should mean what it says everywhere; two dates side by side in different formats would confuse
Meanwhile	Tell the reporter the browser-language workaround now, and that the picker is coming	Nobody waits on the build
Which day a week starts on	A setting - "First day of the week" - Monday unless changed, in System → Date and time formats and in each analyst's Preferences, like the formats	Opinions genuinely differ by country
Rollout	Everywhere at once: one script upgrades every box, with an opt-out for a box that must stay native	One look across the app from day one, and no screen has to change
Phones and tablets	Keep the device's own picker	It is what people expect on a touch screen, and it is good there

Care needed

• Required and validation. The visible box carries required, min, max and disabled from the hidden one, so the browser's "please fill in" still points at something you can see.
• Typed text is read in the chosen format (05/08/2026 is 5 August when the format is day-first); anything it cannot read is refused on the spot rather than saved wrong.
• The portal follows the install's default format, as it already does for everything it shows.
• Clearing a box clears the value, as the native box does.