My watch keeps going for an hour


#1

Hello !

How can I set the time in trueOS ?
My watch keeps going for an hour, even though I’ve set the correct time zone …

Thanks and greetings,
Max.


#2

This post might be the answer to your question.
If it’s not, there is always the # date command.


#3

… unfortunately it’s the same after this …

  • it is 17:04 in central Europe but the time on trueOS ist 16:04 …

#4

Never heard something like this.
What happens when you enter the command # date {yyyymmddhhminmin} for example # date 201802091722


#5
  • there comes the right information:
    [max@myBSD] /usr/home/max# date 201802091722
    Fr. 9 Feb. 2018 17:22:00 CET

  • and the time in the XFCE4 status bar is also correct now


#6

With # rc-status | grep ntp you can see, if openntpd is running. If yes, your time will get adjusted to the correct value.
If you are dual booting with Windows and have chosen the hardware clock to be UTC with TrueOS, than you have to adjust the system times always when switching the operating systems since Windows writes the local time to the hardware clock.


#7

Dont know why from a techncal aspect, but I was having the same problem no matter what I did in the OS with time/ntpd etc… Turns out my BIOS clock was way off… When I reset it, the time in TrueOS was correct. (Still from the tech side , I am not sure if my time syncs with time server, but at least it is correct in lumina)


#8

With the command # ntpd -d you can see the synchronizing process until you terminate it with CTRL+c.
Here the output from my system:

# ntpd -d
ntp engine ready
constraint request to 2a00:1450:4016:809::2004
constraint request to 172.217.20.228
tls connect failed: 2a00:1450:4016:809::2004 (www.google.com): connect: No route to host
no constraint reply from 2a00:1450:4016:809::2004 received in time, next query 900s
constraint reply from 172.217.20.228: offset -0.094058
reply from 80.127.152.30: offset 0.005608 delay 0.045213, next query 6s
reply from 5.9.80.113: offset 0.006954 delay 0.045752, next query 9s
reply from 193.225.50.69: offset 0.005175 delay 0.077661, next query 7s
...

So my system time is exact enough compared to some different time servers.
To see the exact current time (UTC) you can take a look at timeanddate.


#9

Thanks for the info! Looks like openntp is running and I am -28 seconds off. I just booted, so I assume that it will autocorrect soon enough.


#10

Anybody knows how to change/revert this option in TrueOS (UTC hardware clock)?

I’m dual booting with Windows, BTW…


#11

Openntpd has different formation for ntp.conf, openntpd version also lives in /usr/local/etc

ntpctl -sa is what I use check the state of sync.

BIOS time (hardware RTC) is typicallys used to seed system time during boot. That gives NTP a starting point, talking to configured servers causes adjustment.
If the seed is “too far off”, NTP won’t adjust the clock; that’s why there is the ntpdate command (may not be available anymore) that is designed to run early in system boot, talk to a single NTP server and force the system time to get set.

Most sane systems (*nix systems) work much better if the BIOS clock is set to UTC, Windows being Windows (not sane) wants BIOS clock set to local time.

On the command line in *nix systems, the date command reads current value of system time (in UTC) and applies and offset to convert to localtime. This offset comes from the configured TimeZone, which gets information from tzdata files primary source is in FreeBSD base, there is probably a port to grab newer versions.

All of this is part of the explaination why dual boot Windows/*nix systems gets to be a big pain in the butt. If you set the BIOS clock to UTC *nix is happy, Windows isn’t. Set it to localtime, Windows is happy, *nix isn’t. A way to cheat is set BIOS to localtime and tell *nix a different timezone. I believe most clock widgets on *nix honor whatever system setting is done for timezone; you just may lose automatic adjustments for daylight savings time.

I don’t dual boot, so all my BIOS clocks are always set to UTC; toss in NTP and things just work.

In theory, Windows is supposed to be able to use a “timeserver” (I think may SNTP not true NTP) which may let you set BIOS to UTC, but I’ve never had luck getting that to work.

If you’ve read this far, I hope I didn’t “waste your time” with the explaination above :slight_smile:


#12
% man adjkerntz | grep -A 3 'Empty file'
     /etc/wall_cmos_clock  Empty file.  Its presence indicates that the machine's
                           CMOS clock is set to local time, while its absence
                           indicates a UTC CMOS clock.

#13

I’m also at CET (live in Sweden). Since I didn’t find any solving on that at the time, I simply did set the clock inside BIOS.


#14

If anybody is still interested:

Lumina Desktop Environment:

"Control Panel"="System Control Manager"="machdep"="adjkerntz"

This is of course the same as:

% sysctl -d machdep.adjkerntz; sysctl machdep.adjkerntz
machdep.adjkerntz: Local offset from UTC in seconds
machdep.adjkerntz: 0

#15

This empty file solved it here. Thanks!