Allow setting the date format to your region

psy-q

Currently the date picker in the "time" filter seems to be hardcoded to US format (mm/dd/yyyy). I want to choose my own locale's format instead.

No one in their right mind would want the month to be first 😉

But really, most software follows your locale or allows setting it explicitly, so Kagi should, too.

RoxyRoxyRoxy

No one in their right mind would want the month to be first 😉

Gonna have to disagree with you there, mm/dd/yyyy supremacy 🙂
But actually this seems like a good idea, esp for technical users used to yyyy/mm/dd

pixel

@psy-q @RoxyRoxyRoxy

The format depends on your browsers settings, I believe.
For example, my date picker is yyyy-mm-dd formatted.

(example - my locale is set on the browser on the right, the browser on the left is using US format)

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date

I am not sure that there are options to change this with the default date picker without making our own, though.
(not saying we can't do that, but it does have the benefit of being native at the moment)

psy-q

Ah, I see, they write that it's "based on the locale of the user's browser" but that seems to be problematic. My browser locale for example is en_US.UTF-8 but my regional settings are all for de_CH.UTF-8. Operating systems allow this distinction so I get English language UI with Swiss (German) formatted dates, which is what I'd expected to see in the date picker 🙂

I have this setup on Linux at home and a Windows machine at work but the browser (Firefox) is not honoring it on either OS, or it might not have any way to access it. I wonder what Mozilla considers to be "the locale" if there are multiple, one for number formats, one for date formats, one for currencies, etc. I will check the source to see if they do anything with the other locale elements and if there's a way for sites to read the info.

But worse news (I guess?), some date pickers seem to use the accept-language header instead. This is also misguided as the language doesn't necessarily have anything to do with the preferred date format, but at least Duck Duck Go for example gives me dd/mm/yyyy with en-GB on top and mm/dd/yyyy with en-US. Sorry for mentioning the obvious competition! Kagi gives me mm/dd/yyyy in both cases.

I guess if there's no way to get at the detailed locale elements from the OS, using accept-language would be one way to do it. In case I find out how Firefox and Chromium-based browser interpret "the locale", I'll leave a reply here.

Hanbyeol

Minor related, but I also suggested changing the date format in search results.
This is because East Asians (where I come from) tend to use the YYYY-MM-DD format.

https://kagifeedback.org/d/5466-suggestion-arabic-numerals-in-cjk-date-displays

psy-q

Found it without diving into the source: https://firefox-source-docs.mozilla.org/intl/locale.html#regional-preferences

So it seems even the documented way is way more error-prone than I expected and there might be surprises. For the Chromium source, I didn't really find anything yet, they do refer to GLIBC locales (which would suggest they honor LC_MESSAGES vs. LC_TIME) but I'd have to test this to make sure.

psy-q

Tested a bit more. It seems the Kagi picker gets its format from the user interface language of the browser and from nowhere else. Any operating system settings etc. are ignored or not passed on by the browser. After all this testing, I am:

Sad about the sorry state of this in the browser market
100% convinced we need an explicit option in our Kagi account settings 🙂

This is on a system with the following locale settings:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_CH.UTF-8
LC_TIME=de_CH.UTF-8
LC_COLLATE=de_CH.UTF-8
LC_MONETARY=de_CH.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT=de_CH.UTF-8
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Firefox

Interface language:
- German: dd.mm.yyyy
  - English (UK): dd/mm/yyyy
  - English (US): mm/dd/yyyy

Changing accept-language has no effect.

Vivaldi

Interface language:
- German: dd.mm.yyyy
  - English (UK): dd/mm/yyyy
  - English (US): mm/dd/yyyy
Date and time format:
- "Inherit from Operating System": Does nothing on Kagi. Still uses the one from "Interface language". However, the preview values shown in the Vivaldi interface are correct: dd.mm.yyyy.
- "Same as selected language": Behaves like "Inherit from Operating System"

Changing accept-language has no effect.

Chromium

Defaults to US mm/dd/yyyy. Ignores operating system settings/locale. No options exist in-browser to change the formats. No options to change interface language.

Passing LANG=de_CH.UTF-8 as env var results in German user interface and dd.mm.yyyy on Kagi.

Changing accept-language has no effect.

Brave

Defaults to US mm/dd/yyyy. Ignores operating system settings/locale. No options exist in-browser to change the formats. No options to change interface language.

Passing LANG=de_CH.UTF-8 as env var results in German user interface and dd.mm.yyyy on Kagi.

Changing accept-language has no effect.