1

When I run the command date it returns my local time:

qua 22 mar 2023 14:02:33 -03 

When I run the command date -u it returns London time (UTC-00).:

qua 22 mar 2023 17:03:08 UTC

Now, when I run the command hwclock --localtime it returns London time:

2023-03-22 17:04:12.515888-03:00

When I run the command hwclock --utc it returns my local time:

2023-03-22 14:05:11.123389-03:00

Command date presents correct info; however, hwclock --localtime is printing UTC-00 (London time), but it should print my local time (UTC-03)...

  • hwclock -l should print utc-03 (where I am);
  • hwclock -u should print utc-00 (London).
  • hwclock is printing the opposite info.

How to fix that?

2
  • 2
    Note also that London time ≠ UTC!
    – FedKad
    Commented Mar 22, 2023 at 17:49
  • As the hwclock man page says (see option -r, default when no function is specified), "the time shown is always in local time". This is precisely what hwclock is doing: it reports times at -03:00. The --utc and --localtime options do not do what you think (check the man page). --utc means: interpret the hardware clock as set to UTC, even if it isn't. As UTC is +3 relative to you, correcting it to local time means subtracting 3. Vice versa for --localtime: interpret the hardware clock as set to localtime, therefore present it exactly as is.
    – zwets
    Commented Mar 23, 2023 at 0:33

1 Answer 1

3

My system also acts similar to yours. But, this is normal. I am assuming that your hardware clock is set to UTC. For this, check the last line of the timedatectl command output:

 RTC in local TZ: no

means that your hardware clock is set to UTC.

Checking the man page for hwclock:

-l, --localtime; -u, --utc

Indicate which timescale the Hardware Clock is set to.

The Hardware Clock may be configured to use either the UTC or the local timescale, but nothing in the clock itself says which alternative is being used. The --localtime or --utc options give this information to the hwclock command. If you specify the wrong one (or specify neither and take a wrong default), both setting and reading the Hardware Clock will be incorrect.

If you specify neither --utc nor --localtime then the one last given with a set function (--set, --systohc, or --adjust), as recorded in /etc/adjtime, will be used. If the adjtime file doesn’t exist, the default is UTC.

Note: daylight saving time changes may be inconsistent when the Hardware Clock is kept in local time. See the discussion below, under LOCAL vs UTC.

My understanding is this:

Assume current time 17:03 UTC. Your local time for your current time zone is 14:03 (UTC-03). Note that, only the operating system has the notion of time zones; the hardware clock knows nothing about time zones.

Now assume that your hardware clock (aka the Real Time Clock or RTC) is set to UTC (and not to your local time), in other words, is it set to 17:03. BTW, setting the hardware clock to UTC is the recommended method if you are not dual booting with Windows.

The command hwclock --localtime says "bring me the hw clock's current local time assuming that the hw clock is set in localtime". The command will assume that the value returned by the hardware (17:03) is in local time already and it will just print 17:03.

The command hwclock --utc says "bring me the hw clock's current local time assuming that the hw clock is set in utc". The command will assume that the value returned by the hardware (17:03) is in UTC and it will convert to your local time, and print 14:03.

To reiterate:

  • --utc means assume the hardware clock is set to UTC.
  • --localtime means assume the clock is set to local time.

In all cases, hwclock prints the time received from the hardware by converting it to local time. Since, UTC is +3 from you, to print the local time it must subtract 3 hours when you tell it (with --utc) that the clock is set to UTC. But, it shows the time of the clock unmodified when you tell it (with --localtime) that RTC is already set to local time.


You can also run the hwclock commands with the --test or --verbose option to see more details.

6
  • Hi FedKad, so; I ran timedatectl set-local-rtc 1, and now i have: RTC in local TZ: yes. In my opinion we should not have --localtime and --utc, because hwclock returns what defined by timedatectl (0|1, utc or local). These options do not calculate UTC/Local hours when i run hwclock even only for info. In my case, both options (localtime and utc), --localtime is higher than --utc as you can see in my question, but my real UTC is -03, so localtime should be minus 3 hours than utc, unless timedatectl set-local-rtc 0. Commented Mar 22, 2023 at 18:46
  • And In any case (--utc/--localtime, set-local-rtc 0/1); --localtime is +3 hours than utc but my real localtime is -3 hours than utc. Both options are useless and are printing wrong info Commented Mar 22, 2023 at 18:52
  • @LuizCarlos read the hwclock man page before accusing the options of being "useless and printing the wrong info". They act exactly as specified in the man page.
    – zwets
    Commented Mar 23, 2023 at 0:36
  • @zwets of course i read, but the printed output in my machine differs from the reality. Only hwclock with no --localtime nor --utc prints right info. Comparing both options as i said: --localtime should display -3 hours related to --utc printed output when set-local-rtc 1 is set and the oposite ocurred (--localtime +3 hours). If your system is OK, good for you! Commented Mar 23, 2023 at 1:05
  • 1
    See my comment under the question: --utc means consider the clock as set to UTC, and --localtime means consider the clock as set to localtime. In all cases, print local time. As UTC is +3 from you, to print the local time it must subtract 3 when you tell it (--utc) that the clock is set to UTC. Localtime is 0 from you, so it shows the time of the clock unmodified when you tell it (--localtime) that it is set to localtime.
    – zwets
    Commented Mar 23, 2023 at 1:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .