[SOLVED] What is wrong with this computer time + Debian 9?

dedec0 · 09-24-2017, 11:11 AM

Quote:

Originally Posted by Rickkkk

- Make sure your computer is properly configured with respect to its time zone. This is usually initially done at system install, but obviously can be changed if you travel. In Arch (the system I use), this is done on the command line, but Debian probably has a GUI tool to manage this.

Rickkkk, I left this part of your post separated because seems better. Recently I have installed Debian in another partition in this computer, but I do not remember to see an option to choose hardware clock as local or UTC. When this happens? I vaguely remember an install step where we choose timezone... but no UTC x local hardware association was there, or it was not obvious to me.

The situation of the computer is this: it came with a preinstalled Debian with some unusual or strange things for us. And it is not yet booting from other partitions (this will be solved in another thread, not too far from here). Repeating what I said in the previous post: I need to change those things now, after OS is completely working.

Rickkkk · 09-24-2017, 11:26 AM

Quote:

Originally Posted by dedec0

... I want to: use computer's clock as localtime in all installed OSes, if it is not yet doing so; configure this Debian install to know that, and work according to that. Debian may change the hardware clock with NTP if it gets a bit wrong. All of this may involve global system settings, kernel settings or anything else I did not mention. I want to be sure that every possible detail is corret. May you help me here?
..

Hi again Dedec0,

Setting the hardware clock to be interpreted as local time is not recommended best practice for linux systems, but if you would like to do so nonetheless, this command should be used (as root):

Code:

timedatectl set-local-rtc 1

Although you are using Debian, I would recommend reading the section in the Arch Linux Wiki on Time management in linux - the information is mostly generically applicable to any linux system.

https://wiki.archlinux.org/index.php/Time

Cheers and don't hesitate to come back should you have any other questions.

dedec0 · 09-24-2017, 11:28 AM

Quote:

Originally Posted by jpollard

I see you got better info.

As others have said, /etc/localtime should either contain the proper default local time, or be a symbolic link to the right one. I like the use of the symbolic link as the info in /usr/share/zoneinfo/... documents what timezone you have without having to decode the contents (it is a binary file).

(: All people that replied here their part in the solution I am very close to completely do. I am still not sure of what I should do with /etc/localtime. I asked this, together with details of what I want to this computer in #15.

This is the third consecutive post I am doing after a few (also consecutive) replies that were made in the last few hours. #15 expects the important final details. The other two are comments, and do not expect much.

dedec0 · 09-24-2017, 11:35 AM

Rickkkk, I will use that command. I am choosing hardware clock = localtime because this computer will eventually boot with OSes that would behave wrong. Since linux seems to be good to deal with both situations, I am making it do that. I will read the page you pointed later, as I will also read the other two pages colorpurple21859 said in #13.

Now I must do a few "serious" things.

Thread seems close be to solved... yes! ^,^

Rickkkk · 09-24-2017, 12:00 PM

Hi dedec0,

Glad we were able to help. If you are interested in knowing how Windows can be configured to interpret the hardware clock as UTC time, there is a section in the Wiki page I linked you to that explains how to do that.

Otherwise, your solution will also do the trick.

Cheers - let us know if we can help with anything else !

dedec0 · 09-24-2017, 02:27 PM

Hello again, people.

Right now, in a small break, I did one more thing: the timedatectl command. But the big bold warning it gave me is a little puzzling. Look the output of timedatectl before and after the "HW clock = localtime" setup:

Code:

16:09:12 [  0] root@debian: ~
# timedatectl # data e hora do sistema
      Local time: Sun 2017-09-24 16:09:26 -03
  Universal time: Sun 2017-09-24 19:09:26 UTC
        RTC time: Sun 2017-09-24 19:09:26
       Time zone: America/Sao_Paulo (-03, -0300)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

16:09:26 [  0] root@debian: ~
# timedatectl set-local-rtc 1

16:11:11 [  0] root@debian: ~
# timedatectl # data e hora do sistema
      Local time: Sun 2017-09-24 16:11:14 -03
  Universal time: Sun 2017-09-24 19:11:14 UTC
        RTC time: Sun 2017-09-24 16:11:14
       Time zone: America/Sao_Paulo (-03, -0300)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: yes

Warning: The system is configured to read the RTC time in the local time zone.
         This mode can not be fully supported. It will create various problems
         with time zone changes and daylight saving time adjustments. The RTC
         time is never updated, it relies on external facilities to maintain it.
         If at all possible, use RTC in UTC by calling
         'timedatectl set-local-rtc 0'.

Local RTC cannot be fully supported? Why? How that is? Timezone changes will not happen here. Daylight saving adjustements should be normal, I imagined (imagine) no worries for them too. RTC being adjusted is something I thought was configured to be made, since the same command shows:

Code:

Network time on: yes
NTP synchronized: yes

To end the warning, the reverse command to what I just did is shown.

And... ? May I leave it as now, with all wanted ideas I showed in this thread?

Rickkkk · 09-24-2017, 05:05 PM

Hi dedec0,

I admit that that warning is rather heavy-handed, but it is basically telling you, in more detail, why doing this is not considered best practice in linux (as I mentioned in my previous post).

That said, you don't have to worry about anything - your system will work the way you want it to with respect to time management. It is giving you the command to set the rtc clock (hardware clock) interpretation back to UTC for your information only, should you decide to undo the change.

Bottom line, you're good to go.

Cheers,

dedec0 · 09-24-2017, 05:24 PM

Great. I just wanted to confirm, Rickkkk. (=

And the warning says that daylight adjustments will *not* be made. Isn't this a bit wrong sentence, since the NTP server will do it in my kind of situation? Eventually I would have to manually adjust the clock with hwclock or BIOS, and that is fine. I do not change clock in phones, but I do it in the wall clock and in the alarm clock - and I expect no evolution for them. hehe Heavy-handed indeed, I would vote for that to change, or to give more fair details. Little bug?

Rickkkk · 09-24-2017, 06:50 PM

Hey dedec0,

I can't speak to how Debian manages its stuff - I've never used it. I guess they just want to make users understand that making that change is not their recommended solution.

Hope it all works out for you - Boa tarde !

dedec0 · 09-24-2017, 07:38 PM

Hey again. (:

Well, Debian has some extreme actions (at least some of them look like) with some things, but I like that. Their actions for free (as freedom) software are something I value a lot. Together with the fact that it is a top linux distro, for security and features, in the *world*, is a reason for my decision to try it. My reason to want "hw time = local" is practical, but will also not make much difference. Even if this Debian machine had users from different timezones, they would be able to have "their" clock always right, in their uses, for whatever they could do.

On the other side of things, today I tried to watch an MP4 (H264) and it did not work. OGV is already there, why isn't an open technology more used around? "Because it was never like that", like I read(ed) about MP3 several times. Well... I believe in changes!

Boa tarde pra ti também! E uma boa noite! (aqui já são mais de 21:30)
->
You too have a nice afternoon! And a good night! (here already passed from 21:30)

:D

michaelk · 09-24-2017, 07:45 PM

NTP has nothing to do with time zones or Daylight Saving adjustments. Its all buried in your timezone data. None of my physical computers run systemd so I have not played with timedatectl much or how it syncs time with the RTC.

In a nutshell your system clock is a counter that represents the number of seconds since the linux epoch (00:00 1 Jan 1970 UTC). NTP is also based on UTC so when you sync time there is no conversion. In general the RTC is an integrated circuit clock chip that has no reference so the operating system needs to know whether it is set to UTC or local time.

The RTC's sole purpose is to set the system clock at boot time. Once ntp is running the system clock stays synced to UTC. Upon shutdown the RTC is synced to the system clock. ntp does have modes whereby the RTC stays synced to the system clock and its drift rate is determined.

By default timedatectl implements a SNTP client to sync time which is much simpler then running ntp. Without knowing exactly how it works I would guess that it might have problems with the RTC not being set to UTC. Since your running ntp all should be ok as far as I know.