Bug 240047 – Date times do not respect the system's 12/24-hour time format override

• Status: NEW
• Component: New Bugs

[Mike]

Created attachment 458766 [details]
Screenshot showing the system's Language & Region setting and bug in STP

With a 12-Hour time region like United States, when formatting a date with .toLocaleTimeString(), the result is a 12-Hour time even if the system is set to 24-Hour. Conversely, if your region does normally use 24-Hour time, like Germany, having the 24-Hour time format disabled is not reflected in the date time.

The same follows for the "time" input type, but only on macOS. iOS and iPadOS both render this correctly with the overriding setting.

To test on macOS, go to System Preferences > Language & Region and check the 24-hour time format if in a 12-hour time region or uncheck it if in a 24-hour region. On iOS/iPadOS go to Settings > General > Date & Time and enable or disable 24-Hour time.

Run `(new Date()).toLocaleDateTimeString()` in the console and render `<input type="time" />` in HTML.

Both should reflect the system's 24-hour time override setting, but do not.

[Alexey Proskuryakov]

CC'ing some folks who would know if this is an intentional anti-fingerprinting measure, or a bug.

[Yusuke Suzuki]

`(new Date()).toLocaleDateTimeString()` is expected result. Intl DateTimeFormat does not support user's system preference, because of fingerprinting issue.
Adding @akeerthi for input.

[Aditya Keerthi]

Ignoring the system preference in <input type=time> was an intentional anti-fingerprinting measure. As it stands, 12-hour and 24-hour time inputs have different sizing behavior that is discernible by the web page. For date/time inputs, our current behavior is designed to avoid exposing any additional information that is not already exposed through `navigator.language`.

The iOS implementation is much older (and separate) from macOS, and may need to be reconsidered to match privacy guarantees.

[Mike]

Fair enough, thank you all for the insights! I hope the iOS implementation of time inputs regresses to match macOS because as it stands, it seems like a bug to the end user.

[Myles C. Maxfield]

Another option here is to adjust the implementation of <input time="time"> to make its contents unobservable by the webpage. Then it could potentially take users' preferences into account.

This approach won't work for toLocaleDateTimeString() though, of course.

[Radar WebKit Bug Importer]

<rdar://problem/93063198>

[John Wilander]

(In reply to Myles C. Maxfield from comment #5)
> Another option here is to adjust the implementation of <input time="time">
> to make its contents unobservable by the webpage. Then it could potentially
> take users' preferences into account.
> 
> This approach won't work for toLocaleDateTimeString() though, of course.

Wouldn’t the page be able to distinguish the width of a rendered time string? That’s a classic circumvention of attempts to hide characters or even fonts.

[Myles C. Maxfield]

(In reply to John Wilander from comment #7)
> (In reply to Myles C. Maxfield from comment #5)
> > Another option here is to adjust the implementation of <input time="time">
> > to make its contents unobservable by the webpage. Then it could potentially
> > take users' preferences into account.
> > 
> > This approach won't work for toLocaleDateTimeString() though, of course.
> 
> Wouldn’t the page be able to distinguish the width of a rendered time
> string? That’s a classic circumvention of attempts to hide characters or
> even fonts.

When I say "make its contents unobservable," I'm including "width" in the notion of "contents."

Or, said a different way, one of the requirements to make its contents unobservable is to hardcode the width of the element so it doesn't depend on the string width.

[John Wilander]

(In reply to Myles C. Maxfield from comment #8)
> (In reply to John Wilander from comment #7)
> > (In reply to Myles C. Maxfield from comment #5)
> > > Another option here is to adjust the implementation of <input time="time">
> > > to make its contents unobservable by the webpage. Then it could potentially
> > > take users' preferences into account.
> > > 
> > > This approach won't work for toLocaleDateTimeString() though, of course.
> > 
> > Wouldn’t the page be able to distinguish the width of a rendered time
> > string? That’s a classic circumvention of attempts to hide characters or
> > even fonts.
> 
> When I say "make its contents unobservable," I'm including "width" in the
> notion of "contents."
> 
> Or, said a different way, one of the requirements to make its contents
> unobservable is to hardcode the width of the element so it doesn't depend on
> the string width.

Got. That sounds workable from an anti fingerprinting standpoint.