Problem with Bios settings and Linux UTC Time?

    Hello,

    my Libreelec system set at shutdown, my Bios clock to UTC Time. I configure the Linux to CET but nothimg help realy.

    Is there a Problem in systemd?

    System is installed on a radxa X4 bord with realtime clock and battery.

    Connect via SSH to your LibreELEC device. Run the following command to check the current time:

    Shell session
    date

    If the date shown is in the past try forcing an NTP sync:

    Shell session
    ntpd -q -p pool.ntp.org

    Thank you for your replays.
    I have no Problem with my Timezone, all works fine in Kodi.

    This Device starts up automaticly and if I set the correct Bios Time, Libreelec overide it with UTC Time.

    That is all correct in Linux, but there is no timedatectl in linux to manage the time zone which is stored in the Bios Clock,

    It is allways UTC Time. Yes, I can adapt this to UTC Time, but than I have to adjust the Bios time all half year, when it change Summer or Winter Time. My goal is, to store the local Time in BIOS, not UTC Time.

    Sounds like you use dual boot on your machine. In that case you would thinking in the wrong direction.

    If you would use your local time in BIOS, both or multiple operating systems would change the time in your hardware clock and you will end with at least with 1 hour away from your correct time, after summer / winter time change.

    The correct way is to set your BIOS to UTC, then it must only corrected if hardware clock differs from NTP time. Requirement: Linux and Windows should set to use UTC for hardware clock to be fine.
    The selected timezone within the operating system will then lead to add/subtract the delta automatically to show you the correct local time during your operating system session, without touching the BIOS time.

    To set Windows to use UTC for hardware clock there must the registry key RealTimeIsUniversal explicit set: https://the.hosting/en/help/nastro…a-raboty-po-utc

    I'm using that setting for dual boot systems without issues for decades.

    No,

    it doesn't sounds like that but it is the same Problem,

    but an solution is tricky because I cannot set a local Time Environment in the Bios settings, like CET or EST . The system starts with the Bios auto Bootup settings.
    The time in Bios is litteraly irrelevant, but it shoud reflect the Summer-/Wintertime differences,

    that's why if you use it for startup it should go with local Time and UTC is not useful with Summer and Winter Time option, because it's universal.

    You seems to misinterpreting my post.

    UEFI or BIOS has since beginning never supported daylight saving (summer / winter time switch) in general. Maybe that are exists some exotic ones.

    The BIOS shows the hardware clock time, and therefore it should contain the UTC time, if you want it use with an time zone settings of an operating system. This is independend of the operating systems name: Linux, Windows, MacOS, FreeBSD, Android ...

    To set the hardware clock to a value which already includes the timezone differences make it pointless complicated. That was a decision of Microsoft to force that for their Windows operating systems by default, but forces the issues you want to prevent.

    Every modern operating system (since more than 20 years ) is able to add the required difference to the UTC value of hardware clock. Only Windows requires the mentioned additional registry key to drop the idea to set the hardware clock to local timezone value.
    The default behaviour of Windows is the only known operating system that causes the daylight saving issues, as it updates on every summer time and winter time change date the hardware clock to local time - or changes the time retrospectively at the upcoming days if was shutdown at point in time.

    The in the background working Win32 time service covers the issue to often, but in fact it's wrong. Windows is able since the Windows 2000 age at least to add/subtract the required difference to timezone dynamically.
    Linux prefer UTC since it's beginning and has only as dirty workaround, for the Windows affected user, an option to set the hardware to local time as well. Some distributions support that now to make the switch more easy from Windows to Linux, but the approach is counterproductive as it leads to the summer / winter time issue in dual boot scenarios.

    The technical/mathematical issue with BIOS (hardware clock) in local time is, that every installed operating system is believing to make the required change to the hardware clock. After the event, the operating system sets a flag in the OS internal configuration that it has made the change for this year. This flag is not set in BIOS/UEFI and therefore not available for other installed/bootable operating systems. So if you start the next available operating system it will try to make the change again. Depending how many systems you use in parallel it will cumulate and the shown time will far away from your local time.
    Only a working NTP/Win32 time services prevents you in this situation from drifting to far away.

    Like mentioned, set BIOS to UTC and you will be fine. Windows installations require one-time the registry key is set.

    Yes, you can ignore the technical facts and set the hardware clock to local time. But please don't be surprised if the automatic daylight saving (summer / winter time change) doesn't work like you expected.

    I don't misinterpreting your post.
    I know this feature in Windows and Linux but I do not use 2 operating systems,
    This Problem exist between Bios Clock/(Bootup Time) and synchronisation of Linux UTC Time with Bios Clock.

    The expected behaviour is:

    • BIOS/hardware clock is running in UTC
    • System boot and catch the value of your hardware clock and translate it from UTC to your local set timezone. The timezone setting template of the system respects also daylight saving dates and add 1 hour in summer months and don't add that 1 hour in the winter months.

    As your system sets during shutdown the hwclock to UTC, it's to assume that it also know at boot time that the values from hwclock are UTC. If you would manipulate in BIOS to local time a miscalculation would occur.

    What is your reason for keeping the time given in local time? Do you suspect that reference time differs between boot time and shutdown? Please keep in mind that during LE boot typically NTP servers are asked for current timestamp. There are situations known, where a ISP or router provides a wrong timestamp and trigger offset.

    Addendum:

    If you plan to use some kind of wake up via BIOS schedule, you would require the tool 'rtcwake' to set the next wake schedule automatically. The appropriate place for this would be a startup or shutdown script , but unfortunately, the binary file will be missing. Furthermore, you first need to check whether your Radxa X4 is supported. On that way you would ensure that the time adjustment of the shift date is respected.

    Even if you want to stick with local time, you would need to create the file /etc/adjtime with the following content:

    Code
    0.0 0 0.0
0
LOCAL

    Since LibreELEC is based on a read-only file system, you currently need a custom LE image to achieve this - or at least the rtcwake binary that matches your architecture.

    Edited once, last by HarryH (October 9, 2026 at 5:52 PM).