Bug 240047

Summary: Date times do not respect the system's 12/24-hour time format override
Product: WebKit Reporter: Mike <reingator>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: akeerthi, bfulgham, mmaxfield, pvollan, webkit-bug-importer, wilander, ysuzuki
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: All   
OS: All   
Attachments:
Description Flags
Screenshot showing the system's Language & Region setting and bug in STP none

Mike
Reported 2022-05-03 17:02:20 PDT
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.
Attachments
Screenshot showing the system's Language & Region setting and bug in STP (667.24 KB, image/png)
2022-05-03 17:02 PDT, Mike 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2022-05-03 18:41:09 PDT
CC'ing some folks who would know if this is an intentional anti-fingerprinting measure, or a bug.
Yusuke Suzuki
Comment 2 2022-05-03 18:46:34 PDT
`(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
Comment 3 2022-05-03 20:53:34 PDT
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
Comment 4 2022-05-04 09:38:34 PDT
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
Comment 5 2022-05-04 15:40:59 PDT
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
Comment 6 2022-05-10 17:03:14 PDT
<rdar://problem/93063198>
John Wilander
Comment 7 2022-05-10 19:35:58 PDT
(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
Comment 8 2022-05-10 19:37:48 PDT
(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
Comment 9 2022-05-10 20:36:38 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.