Configuration of the current time shown by SDDM

I have one system (my laptop) which displays the current time in the SDDM greeter as HH:MM:SS
However, on my other system (desktop/workstation) the current time in the SDDM greeter is only displayed as the HH:MM format

Anyone know off hand how to set the seconds to appear in the desktop’s case too?

Areas I’ve poked around in but didn’t see an obvious solution

  • /etc/sddm.conf
  • /usr/share/sddm/themes
  • system settings > (Personalization) > regional settings
  • system settings > {Workspace) > Startup and Shutdown > Login Screen

I suppose it uses the system’s locale settings.

You should be able to change it in /etc/sysconfig/language or with localectl.

Changing the locale settings in systemsettings5 won’t help because these are for the current user only, sddm runs as a different user though.

Try running the following in an elevated console, modify what you want to have displayed, substitute the placeholders with real values(doesn’t have to be accurate since the last step is to re-sync with a time server)

timedatectl set-time YYYY-MM-DD HH:MM:SS

Then, re-sync time, assuming you have ntp configured

systemctl restart ntpd.service

TSU

To accomplish this, edit the components/Clock.qml file in your sddm theme. For the default openSUSE SDDM theme this would be:

sudo vim /usr/share/sddm/themes/breeze-openSUSE/components/Clock.qml

Edit line:

text: Qt.formatTime(timeSource.data"Local"]"DateTime"])

To:

text: Qt.formatTime(timeSource.data"Local"]"DateTime"], "hh:mm:ss")

You can edit your date format as well:
Edit line:

text: Qt.formatDate(timeSource.data"Local"]"DateTime"], Qt.DefaultLocaleLongDate)

To:

text: Qt.formatDate(timeSource.data"Local"]"DateTime"], "yyyy/MM/dd")

Please note upgrades will overwrite the changes to the default SDDM themes. Copy the theme under another name to prevent this.

Yeah, but unfortunately, I don’t see any differences in the settings between those set for the laptop and the desktop’s.

Changing the locale settings in systemsettings5 won’t help because these are for the current user only, sddm runs as a different user though.
I agree, but changing some of the settings should invoke a request for root privaleges in order to make the change on the global scale … For that matter, the only reason why I even looked into the systemsettings route was from a google search that lead me to an older thread (from elsewhere) that described a different problem but provided hope for a potential similar solution pathway (see http://forums.netrunner-os.com/showthread.php?tid=18371)

Thanks for the suggestion. However, the system is already correctly using HH:MM:SS … In any regard, messing around with it nonetheless, what is interesting is that running the set-time option is not working for me

# timedatectl set-time 2016-10-23 22:47:54
Invalid number of arguments

:confused: Shrugs.

Thanks, that did indeed produce the desired change. Duly noted about the modification being subject to update overwriting.

What I didn’t convey in my original message was that I haven’t been able to find a difference between the laptop and the desktop’s settings that would explain the observed difference. For example, both machines had the same unadulterated clock.qml files. So, it would appear that some locale setting on the laptop is set differently then the desktop’s, thus producing the change … The problem is, I just can’t see any difference between the two systems’ settings. Ideally, being able to adjust the local setting would be a more desirable solution, as it would negate the issue of “subject to update overwriting”

Also interesting is that I noticed that when the laptop is suspended, resumption showed only the HH:MM format … though, that’d be the lockscreen I believe, as opposed to SDDM …

And what does localectl say about the “System Locale” in both cases?
There must be a difference…

According to “man localectl”, the locale settings are now in /etc/locale.conf. So compare that file as well, and particular the “LC_TIME=” setting (and/or set it to your likings, but you can do that with “localectl set-locale” as well).

       The /etc/locale.conf file configures system-wide locale settings. It is
       read at early-boot by systemd(1).
...
       The locale settings configured in /etc/locale.conf are system-wide and
       are inherited by every service or user, unless overridden or unset by
       individual programs or individual users.

       Depending on the operating system, other configuration files might be
       checked for locale configuration as well, however only as fallback.

openSUSE did use /etc/sysconfig/language in the past, but I’m not sure if that is still the case in Tumbleweed. In any case, /etc/locale.conf will override /etc/sysconfig/language if it exists.

And they can be overridden by the kernel boot options “locale.LC_TIME=xxx” and so on.

I agree, but changing some of the settings should invoke a request for root privaleges in order to make the change on the global scale …

Yes, but it doesn’t even try to change the locale settings system-wide…

Thanks for the suggestion. However, the system is already correctly using HH:MM:SS … In any regard, messing around with it nonetheless, what is interesting is that running the set-time option is not working for me

# timedatectl set-time 2016-10-23 22:47:54
Invalid number of arguments

:confused: Shrugs.

“timedatectl set-time” wants exactly one argument with the time, so you need to enclose it in quotes because of the space between date and time.
This should work:

timedatectl set-time "2016-10-23 22:47:54"

But this will only set the system time, not the way how it is displayed…

Also interesting is that I noticed that when the laptop is suspended, resumption showed only the HH:MM format … though, that’d be the lockscreen I believe, as opposed to SDDM …

Yes, that’s the lock screen, and uses the user’s locale settings.
SDDM is (only) the login screen.

Actually,
Should also modify how is displayed, so for example the above can be modified to display without seconds by running the following

timedatectl set-time "2016-10-23 22:47"

TSU

Where have you got this idea from? Did you actually test it?

You’re right, what I posted doesn’t work, and I can’t find the reference I used so may have misunderstood what it said.

TSU

Nope; same thing for both:

localectl
   System Locale: LC_CTYPE=en_GB.UTF-8
       VC Keymap: us
      X11 Layout: us

According to “man localectl”, the locale settings are now in /etc/locale.conf. So compare that file as well, and particular the “LC_TIME=” setting (and/or set it to your likings, but you can do that with “localectl set-locale” as well).
Neither system has a /etc/locale.conf

“timedatectl set-time” wants exactly one argument with the time, so you need to enclose it in quotes because of the space between date and time.
This should work:

timedatectl set-time "2016-10-23 22:47:54"

Ummm…I knew that rotfl!

Anyway, I appreciate everyone’s help and suggestions.

Weird.
I’m running out of ideas where the difference between the two systems might be.

But sddm definitely takes the time format from LC_TIME.

I just tried it: if I run “sddm-greeter --test-mode --theme /usr/share/sddm/themes/breeze-openSUSE/” as user, it uses that user’s locale settings for the time format, i.e. there are no seconds. Starting it with “LC_TIME=C sddm-greeter --test-mode --theme /usr/share/sddm/themes/breeze-openSUSE/” makes it use the “C” time format, i.e. with seconds.

So as already explained, you should be able to modify the format by setting LC_TIME accordingly, either in /etc/locale.conf or in /etc/sysconfig/language (the latter is only used if the former doesn’t exist).

LC_TIME=en_GB does not show seconds btw, so apparently on your system with seconds this gets overridden somehow before sddm starts (or something like that).

I would still suggest to compare /etc/sysconfig/language again on both systems. This has several settings maybe you overlooked one.
Just to be clear: RC_LANG sets the language and is taken by default for all other locale settings too, if they are not set.
RC_LC_ALL will set all other locale settings (LC_xxx variables) and overrides everything else.
RC_LC_TIME will set the date and time format. As mentioned, this will be overridden by RC_LC_ALL (if RC_LC_ALL is set), and will use the value of RC_LANG if it is empty.
The rest should be irrelevant here…

I concur. Works for me as well

So as already explained, you should be able to modify the format by setting LC_TIME accordingly, either in /etc/locale.conf or in /etc/sysconfig/language (the latter is only used if the former doesn’t exist).
Yep, just made an /etc/locale.conf file on the desktop with the sole line of LC_TIME=C and it works as desired … and is a better solution than editing EACH theme’s clock file … as it perseveres across theme updates as well as eliminates the need to manually edit each theme you wish to use … (not that I’m using any other theme, but …).

LC_TIME=en_GB does not show seconds btw,
Ah, okay. In any regard, the “C” setting works fine for me.

so apparently on your system with seconds this gets overridden somehow before sddm starts (or something like that).
and that’s the million dollar question, because:

I would still suggest to compare /etc/sysconfig/language again on both systems. This has several settings maybe you overlooked one.
Just to be clear: RC_LANG sets the language and is taken by default for all other locale settings too, if they are not set.
RC_LC_ALL will set all other locale settings (LC_xxx variables) and overrides everything else.
RC_LC_TIME will set the date and time format. As mentioned, this will be overridden by RC_LC_ALL (if RC_LC_ALL is set), and will use the value of RC_LANG if it is empty.
The rest should be irrelevant here…
I did. To verify my eyes weren’t missing anything, I even ran the two files in Kompare, and there is no difference between each system’s copy. So the million dollar question remains open* as to why the laptop displayed the seconds whereas the desktop didn’t without manual intervention/modification.

  • On a personal level, I’m closing the million dollar question, and won’t be bothering to investigate any further (unless someone suggests something that is easy to check) – as its a trivial matter, and the LC_TIME=C suggestion brings about a desired resolution anyway

Thanks again everyone