How to change system time format to specific standard?

I don’t want my date-time representation to change per the country I’m in; I want to be able to choose between specific standards, such as RFC 3339 or ISO 8601, the latter being my preference.

I am easily able to do so on Windows, but don’t appear to be able to do so in the regional settings KCM. Is this possible?

2 Likes

If you want to use the ISO 8601 standard use en_DK.UTF-8 in the Time category in Region & Language KCM.

See 3.3 in the Arch Wiki Locale - ArchWiki

Seems to work fine in the terminal but the Plasma tray Clock has some issues with it?

€: corrected to en_DK

date_time

@Duha,

Typing en_US.UTF-8 into the search bar doesn’t work, so I tried en_US

en_US shows the correct date format in its preview here

However, it then shows the standard US preview when selected

and then doesn’t work.

PS /home/rokejulianlockhart> # en_GB.UTF-8
PS /home/rokejulianlockhart> who -b  
         system boot  2023-05-09 17:08
PS /home/rokejulianlockhart> # en_US.UTF-8
PS /home/rokejulianlockhart> who -b
         system boot  2023-05-09 17:08

so I think who -b is perhaps unaffected…?


That’s controlled separately, unfortunately

1 Like

Sorry I posted the wrong one, I meant en_DK.

@Duha,

That also uses {day}/{month}/{year} like en-GB does.

Hey @rokejulianlockhart,

after setting it to en_DK.UTF8 it looks like this for me:
date_time

after setting it to de_DE.UTF8
date_time_de

You are correct that the ẁho -b command gives the same output.
The date command gives a different output.

Also the System Clock changes. Although not in the way I expected it.

I’m a little bit confused now :smiley:

PS: I uncommented the relevant locales in /etc/locale.conf and run locale-gen (commands might not apply to your Distri.)

Also restart was required.

€: en_DK.UTF-8 also gives me the same preview, which seems incorrect see first screenshot.

PS /home/rokejulianlockhart> who -b
         system boot  2023-05-21 18:09
PS /home/rokejulianlockhart> date          
Sun 21 May 22:33:47 BST 2023

Yeah.

Thanks for your assistance, @Duha – I’ll probably just file an FR at bugs.kde.org rather than potentially corrupt configuration files, since that wouldn’t do any less technically competent users any good (and Plasma should have at least feature parity with Windows).

I’ve changed the topic type from #help to #brainstorm because this is obviously currently impossible.


https://github.com/mucommander/mucommander/releases/download/1.2.0-1/mucommander-1.2.0-1.x86_64.rpm provides a decent demonstration of how to easily design the GUI selector:

image

Sure, and that works fine in a single app. But do you really want to re-define your favorite date format in every single app? Probably not. Which is why it needs to be done centrally, in one place, in a way that all apps that ask for date formats can consume. Which is a lot harder, because the POSIX data standard currently does not easily support defining arbitrary date formats.

In KDE 4 times, we let you define arbitrary custom date formats, bypassing the POSIX locale standard, but it only worked for KDE apps that specifically knew how to read the KDE-defined date format. So people complained that GNOME and other apps didn’t get the same date formatting, and there was no way to fix this issue in principle because we were explicitly ignoring the cross-desktop standard and the GNOME folks (to say nothing of all other software) weren’t going to adopt the KDE thing as a new de-facto cross-desktop standard to replace the existing one. So, in Plasma 5 times, we admitted defeat and went back to supporting POSIX locales so now the format you choose applies to all apps. But as a consequence, you can’t arbitrarily customize the date format.

Those are the limitations and external conditions involved.

3 Likes

Who could create a more modern standard? Systemd? freedesktop.org?

1 Like

It’s far underneath them; it would be the IEEE Computer Society, which maintains POSIX standards.

2 Likes

Idk, maybe its just me, but I was hoping for a more modern standard and using posix just as a fallback if the more modern standard is not available.

Posix: Latest version IEEE Std 1003.1-2017
2017; 6 years ago

(Most) modern Linux Distris already embrace modern technology like systemd, wayland etc…, who knows what the BSD’s and a few small Distris will do? Maybe I’m just naive, but I wish we would move on from projects that want to stay in 1980.

1 Like

Yeah, that was always my suggestion, @ngraham. I don’t believe I’ve stated otherwise, but thanks.


I wholeheartedly agree, @Duha. I believe that

was a retrograde step, as I’m sure the developers who had to choose this path thought too. I don’t mind having to set two similar preferences – we already have the ability to choose a different GTK theme preference. Where it’s necessary, I think that the “Powerful when needed” part of the KDE mantra applies here.

1 Like

https://bugs.kde.org/show_bug.cgi?id=480683#c0

To restate this more broadly, since from the response at id=480683#c3 I don’t believe that this is adequately appreciated, I’ve created gitlab.com/-/snippets/4823517:

The Current State of Standard Adherence in the Stead of Retrograde “Locale” Norms (in OSes and DEs)

  1. plasma-systemsettings-6.3.2-1.fc41.x86_64

    In kcm_regionandlang, I see options to set locales for a multitude of options:

    image

    For each of these, a standard corresponds that I want to prefer, yet which is unavailable in most or all locales:

    QListWidgetItem::setText Status Provided Example Desired Standard Standard Example
    Language
    Inapplicable Inapplicable Inapplicable
    Numbers
    Some
    en-GB 31,000,422.78
    C 31000422.78
    SI/ISO 31-0 [1] / ISO/IEC 80000 [2] 31 000 422.78 Ω
    Time
    None Some really mental stuff, especially in the USA: “9/3/25 11:08:00 PM (London)”. ISO 8601 +2025-03-09T23:08:00+00:00
    Currency
    None £4000.80 ISO 4217 GBP 4 000.80
    Measurements
    Unknown
    Metric
    ISO 1000 / ISO/IEC 80000 [3] SI Units
    Paper Size
    All A-Series (A4) ISO 216 [4]
    A-Series (A4)
    Address
    It’s visible in the screenshot. Read the standard. UPU S42 [5]
    Name Style
    It’s visible in the screenshot.
    Read the standard.
    Inapplicable, [6] but C works. image
    Phone Numbers
    All +44 1234 567890 ITU E.123 and E.164 [7] +44 1234 567890
    Data and Storage Sizes
    Choice of standard is available GiB IEC 60027 [8]

    This isn’t acceptable, for the massive difference in information formatting and density in comparison to what is internationally accepted, and more importantly, what I work with every day, is stark. windows.immersivecontrolpanel_10.0.8.1000 provides options to get a damn lot closer than this. I’d rather have KDE’s applications adhere to my preferences and have these as a fallback then aim for the lowest common denominator.

  2. windows.immersivecontrolpanel_10.0.8.1000 and intl.cpl in OsBuildNumber: 26120 [11]

    ms-settings:regionformatting [12] of windows.immersivecontrolpanel_10.0.8.1000 is very disappointing in comparison to kcm_regionandlang’s GUI and intl.cpl’s functionality, but does provide standard format choices:

    Screenshot_2025-03-09_235709

    intl.cpl is damned perfect in comparison:

    Screenshot_2025-03-09_235527
    Screenshot_2025-03-09_235533
    Screenshot_2025-03-09_235536
    Screenshot_2025-03-09_235539
    Screenshot_2025-03-09_235545

    Additionally, although tangentially related, I’m seriously impressed that these configurations can even be set as the defaults for new users of the OS!

    Screenshot_2025-03-09_235519

Can we talk to FreeDesktop about this?


  1. en.wikipedia.org/w/index.php?title=Decimal_separator&oldid=1277586946#cite_ref-nist.gov_36-0 ↩︎

  2. en.wikipedia.org/w/index.php?title=ISO_31-0&oldid=1226286421 ↩︎

  3. en.wikipedia.org/w/index.php?title=ISO_1000&oldid=1086602120 ↩︎

  4. en.wikipedia.org/w/index.php?title=ISO_216&oldid=1277617890 ↩︎

  5. upu.int/UPU/media/upu/documents/PostCode/S42_International-Addressing-Standards.pdf#page=2 ↩︎

  6. english.stackexchange.com/revisions/621728/1 ↩︎

  7. stackoverflow.com/revisions/21001896/1 [9] [10] ↩︎

  8. en.wikipedia.org/w/index.php?title=IEC_60027&oldid=1242838496#IEC_60027-2 ↩︎

  9. en.wikipedia.org/w/index.php?title=E.123&oldid=1234098403#Example_formats ↩︎

  10. en.wikipedia.org/w/index.php?title=Talk:Trunk_prefix&oldid=1205771844#Reference_for_common_wrong_+61(0)_practice ↩︎

  11. superuser.com/revisions/1884748/4 ↩︎

  12. github.com/MicrosoftDocs/windows-dev-docs/blob/32bb6862eef58455ea3fd2a95cf66f83fa08f4fd/hub/apps/develop/launch/launch-settings-app.md#time-and-language ↩︎

1 Like

Just to take a look beyond end of our collective nose – :smiling_imp:

macOS Sequoia version 15.3.1 –


And, before anyone jumps in –

Operating System: openSUSE Leap 15.6
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.12
Kernel Version: 6.4.0-150600.23.38-default (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 5 3400G with Radeon Vega Graphics
Memory: 29.3 GiB of RAM
Graphics Processor: AMD Radeon Vega 11 Graphics
Manufacturer: ASUS

The Apple screenshots were dropped onto this openSUSE box via NFS to an exported ‘/local/’ folder.

1 Like

@Franken14679, thanks for that! That and GNOME were the last platforms that I wanted to add. I’ve asked GNOME about this at the undermentioned:

Perhaps it’s simpler for macOS because it’s BSD-based…? I’m grasping at straws.

No, I doubt that, that’s the case …

  • Apple is Apple and will probably remain so.
    I’ve been considering purchasing a Mac for more than a few years now –
    Reasons:

  • macOS is a UNIX®.

  • macOS is “different” – you either love it or hate it – no other options … :smiling_imp:

  • My digital camera’s RAW processing is only possible either with MS Windows or, macOS.
    I’ve given up on Windows and Microsoft in general …

  • The default macOS digital photograph application has a quite nice AI feature.

  • I wanted to experience macOS for myself and, a MacBook Air is light enough to be added to my photographic backpack.

@Franken14679, have I news for you!

It is BSD. macOS, like AOSP+GMS, is a customised distribution of Darwin, which uses the XNU kernel. That kernel is solely compatible with a BSD base. Darwin is an amalgamation of NeXTSTEP and freeBSD, with very occasional GNU binaries.

@rokejulianlockhart:

I meant that, it’s possibly the case that, macOS has implemented the system time format feature simply because, they’re Apple – independent of whether or not BSD makes it easier to offer such features or, not.


Regardless, thanks for the investigation – I’ve long suspected that, a UNIX® certification is quite costly and, there’s sufficient evidence showing that, that’s the only reason that, Linux ain’t a certified UNIX®.


BTW, my first contact with a UNIX® was the DEC ULTRIX OS, which was a BSD UNIX® because, DEC and AT&T had a difference of opinion back in the late 1970’s – despite UNIX® as such being initially only available for DEC PDP-11 (16-bit) hardware.

1 Like