Score:0

Ubuntu

What is RTCTimeUSec shown by `timedatectl show`?

AlMo320

3/22/23, 4:40 PM

On assorted flavors and versions of Linux, I see the following when issuing the timedatectl show command:

Timezone=America/Los_Angeles
LocalRTC=yes
CanNTP=yes
NTP=yes
NTPSynchronized=yes
TimeUSec=Mon 2021-11-22 08:33:06 PST
RTCTimeUSec=Mon 2021-11-22 00:33:06 PS

This value appears to be the local time offset by -8 hrs (my current GMT offset), which doesn't make sense to me.

I can't find any reference to this output in Google or man timedatectl. Could be an artifact of set-local-rtc=1 (dual booting with Windows)?

0 + 0

tools

date

Score:0

Ubuntu

emk2203

3/22/23, 5:39 PM

From https://www.freedesktop.org/software/systemd/man/org.freedesktop.timedate1.html

Timezone shows the currently configured time zone. LocalRTC shows whether the RTC is configured to use UTC (false), or the local time zone (true). CanNTP shows whether a service to perform time synchronization over the network is available, and NTP shows whether such a service is enabled.

NTPSynchronized shows whether the kernel reports the time as synchronized (c.f. adjtimex(3)). TimeUSec and RTCTimeUSec show the current time on the system and in the RTC. The purpose of those three properties is to allow remote clients to access this information over D-Bus. Local clients can access the information directly.

If you have Windows still set to local time, this is definitely the cause of the two times differing.

With LocalRTC=no, TimeUSec and RTCTimeUSec have the same value.

To keep the time of the RTC at Universal time for both systems in the dual boot, it's better to force Windows to use UTC as well.

You can do this with the registry value 1 in RealTimeIsUniversal in the Windows registry at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation.

0 + 0

AlMo320

3/23/23, 4:09 AM

Yep, figured as much. Seen the warnings after setting RTC to local zone, still not quite clear to me what harm this will do to Linux apps. Pretty sure Windows apps could care less what zone they're in, like a lot of people I use my PC as a clock. Like most people, I don't live in Iceland or Greenwich, or other places where DST isn't a "thing" every so often, so I'll probably live with that RTCTimeUSec `anomaly` :)

AlMo320

3/23/23, 4:18 AM

Reading the article made me contemplate that we are now officially closer to 2038 than Y2K o>. Who thinks the world will end before we encounter 32-bit numeric overflows? Who believes it didn't end 22 years ago? Personally I'm looking forward to the "end of the epoch" whether there are any 64-bit processors around by then or not!

AlMo320

3/23/23, 4:31 PM

https://www.epochconverter.com/?mm=1&dd=1&yyyy=2039&hh=12&mn=0&ss=0&am=am&tz=1 makes the point: Some systems store epoch dates as a signed 32-bit integer, which might cause problems on January 19, 2038 (known as the Year 2038 problem or Y2038).

AlMo320

3/23/23, 4:36 PM

My question and @emk2203 answer did help me unwravel the awkward acronym of USec which is a "camel case" way to avoid the greek letter 'mu' representing microseconds. Since this question had to do with a Windows/Linux dual boot confrontation point, it's ironic (don't ya think) to find the below passage in a MS Word help file:

AlMo320

3/23/23, 4:36 PM

μ letter is very popular in different domains of science. E.g., μ symbol designates a population mean in statistics, coefficient of friction or magnetic permeability in physics, and micron or micrometer in measurement. https://www.officetooltips.com/word_2016/tips/how_to_insert_micro_sign_or_mu_symbol_in_word.html

AlMo320

3/23/23, 4:41 PM

So, to conclude: why discuss USec in the results of timedatectl, when no POSIX function or subroutine differentiates between μsecs and secs? Especially when the date is displayed as "human-readable" rather than "epoch"?