Hello, thank you for maintaining Chromium.

Unfortunately I cannot report this on crbug.com as it requires a
personal Google account, which I do not have, to sign in.

Given this simple HTML file:

    <form>
        <input type="date" value="2025-01-20">
        <input type="time" value="15:30:45">
    </form>

When displayed on a system with this locale:

    $ locale
    LANG=en_IE.UTF-8
    LANGUAGE=en_IE:en
    LC_CTYPE="en_IE.UTF-8"
    LC_NUMERIC="en_IE.UTF-8"
    LC_TIME="en_IE.UTF-8"
    LC_COLLATE="en_IE.UTF-8"
    LC_MONETARY="en_IE.UTF-8"
    LC_MESSAGES="en_IE.UTF-8"
    LC_PAPER="en_IE.UTF-8"
    LC_NAME="en_IE.UTF-8"
    LC_ADDRESS="en_IE.UTF-8"
    LC_TELEPHONE="en_IE.UTF-8"
    LC_MEASUREMENT="en_IE.UTF-8"
    LC_IDENTIFICATION="en_IE.UTF-8"
    LC_ALL=

I get a date picker with "1/20/2025" format, and a time picker with
"03:30:45 PM" format.

On the same system+locale:

    $ date --date="2025-01-20 15:30:45"
    Mon 20 Jan 2025 15:30:45 CET

/usr/share/i18n/locales/en_IE defines dd/mm/yyyy for dates and a 24h
time for times:

    d_t_fmt     "%a %d %b %Y %T"
    date_fmt    "%a %d %b %Y %T %Z"
    d_fmt       "%d//%m//%y"
    t_fmt       "%T"
    am_pm       "";""
    t_fmt_ampm  ""

Firefox 128.11.0esr on the same system correctly shows the same file
with "20/01/2025" format for dates, and "15:30:45" format for times.

It looks like chromium is not picking up the locale correctly.
Unfortunately I do not have an equivalent chrome to try, but from issues
such as https://github.com/nextcloud/calendar/issues/6359 it looks like
it's a widespread enough problem that is driving various people mad, as
NextCloud is using standard date/time pickers for its calendar input.


Thank you,

Enrico