Solved Daylight saving not recognised

B

bgroper

Hi forum
Daylight saving (+1 hour) commenced in much of eastern Australia at 3.0 am this morning.
So we've moved from 10 hours ahead of GMT to 11 hours ahead of GMT.
My /etc/localtime is pointing to /usr/share/zoneinfo/Australia/Canberra but FreeBSD is now reporting the wrong time.
I can use a kludge and point to /usr/share/zoneinfo/Australia/LHI to get the +11 hours.
What is the-right-way to keep the correct timezone (eg Canberra) and have the time correctly displayed as AEDT ?
BTW, I do have the following line in /etc/rc.conf
Code: 
ntpd_enable="YES"
TIA's for any tips or clues.
 
Last edited by a moderator:
Can you report the version of FreeBSD you're running? I spun up an EC2 instance running FreeBSD 13.1-RELEASE-p2, and was able to set the machine in AEDT:

Code: 
root@freebsd:/home/ec2-user # tzsetup Australia/Canberra
root@freebsd:/home/ec2-user # date
Sun Oct  2 14:10:56 AEDT 2022
 
darmokandjalad said:
Can you report the version of FreeBSD you're running? I spun up an EC2 instance running FreeBSD 13.1-RELEASE-p2, and was able to set the machine in AEDT:

Code: 
root@freebsd:/home/ec2-user # tzsetup Australia/Canberra
root@freebsd:/home/ec2-user # date
Sun Oct  2 14:10:56 AEDT 2022
Click to expand...

Thx Thanks for reply.

Code: 
root@freebsd:~ # uname -a
FreeBSD freebsd 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 GENERIC amd64
root@freebsd:~ # tzsetup Australia/Canberra
root@freebsd:~ # ls -l /etc/localtime
lrwxr-xr-x  1 root  wheel  38 Oct  2 16:44 localtime -> /usr/share/zoneinfo/Australia/Canberra
root@freebsd:~ # date
Sun Oct  2 16:44:41 AEDT 2022

BUT the time should be 17:44:41
What else could be causing this error ??

Edit.
I should have confirmed this instance is running on real hardware. It is NOT a VM.
BTW, the file /etc/wall_cmos_clock does exist in my system.
Is this likely to work better IF I change the BIOS hardware clock to UTC, and delete the /etc/wall_cmos_clock file?
What is the-right-way to do this ?
More TIA's
 
Last edited by a moderator:
I'm running 12.3-RELEASE-p6 which I only updated to -p6 a few days ago, and I did notice there were updates to /usr/share/zoneinfo ... but no changes to .../Australia

My clock updated correctly 02:00 -> 03:00, and I'm NOT running ntpd currently, so my box updated automatically, confirmed by /var/log/cron

I'm using Australia/Sydney, also with wall_cmos_clock

What date are the files in your /usr/share/zoneinfo/Australia? (here Dec 2 2021, 12.3 release date)
 
bgroper said:
root@freebsd:~ # tzsetup Australia/Canberra
root@freebsd:~ # ls -l /etc/localtime
lrwxr-xr-x 1 root wheel 38 Oct 2 16:44 localtime -> /usr/share/zoneinfo/Australia/Canberra
root@freebsd:~ # date
Sun Oct 2 16:44:41 AEDT 2022

BUT the time should be 17:44:41
Click to expand...

I just repeated the tzsetup dance without change, but one change from 12.3 is that /etc/localtime on mine is a copy of /usr/share/zoneinfo/Australia/Sydney, not your symlink.

For reference, all the eastern Oz files (except Qld) are 2195 bytes here, and identical.

Is your /etc/ntp.conf standard? It'd be pretty ironic if 0.freebsd.pool.ntp.org was misleading you ...
 
smithi said:
I just repeated the tzsetup dance without change, but one change from 12.3 is that /etc/localtime on mine is a copy of /usr/share/zoneinfo/Australia/Sydney, not your symlink.

For reference, all the eastern Oz files (except Qld) are 2195 bytes here, and identical.

Is your /etc/ntp.conf standard? It'd be pretty ironic if 0.freebsd.pool.ntp.org was misleading you ...
Click to expand...
Same here on my 13.1-RELEASE-p2 hardware system. I can also report that the permissions are different from what bgroper reports:

Code: 
[user@freebsd ~]$ ls -ltr /etc/localtime
-r--r--r--  1 root  wheel  118 Mar 15  2022 /etc/localtime
[user@freebsd ~]$ date
Sun Oct  2 19:17:23 UTC 2022
[user@freebsd ~]$ sudo tzsetup Australia/Canberra
[user@freebsd ~]$ ls -ltr /etc/localtime
-r--r--r--  1 root  wheel  2195 Oct  3 06:17 /etc/localtime
[user@freebsd ~]$ date
Mon Oct  3 06:18:13 AEDT 2022

bgroper, do you recall how you set the system's timezone in the past? Have you tried using tzsetup() to set the timezone to something other than Canberra to see what effect it has on /etc/localtime?
 
I'm still trying to get to the root (sic) of this problem.
Seems my ntpd service is not playing nice.

Code: 
root@freebsd:/etc # service ntpd status
ntpd is running as pid 1360.
root@freebsd:/etc # ntpstat
unsynchronised
poll interval unknown
root@freebsd:/etc # ntptime
ntp_gettime() returns code 5 (ERROR)
  time e6e4a1b3.0a52d000  Mon, Oct  3 2022 10:48:03.040, (.889040326),
  maximum error 16042500 us, estimated error 16000000 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 5.065 ppm, interval 4 s,
  maximum error 16042500 us, estimated error 16000000 us,
  status 0x41 (PLL,UNSYNC),
  time constant 3, precision 0.000 us, tolerance 496 ppm,
  pps frequency 5.065 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
root@freebsd:/etc #
root@freebsd:/etc # ping 0.au.pool.ntp.org
PING 0.au.pool.ntp.org (103.76.40.123): 56 data bytes
64 bytes from 103.76.40.123: icmp_seq=0 ttl=55 time=7.967 ms
64 bytes from 103.76.40.123: icmp_seq=1 ttl=55 time=6.783 ms
^C

Hmmmm.
 
I'm inclined to agree with tingo that your timezone issue probably isn't being caused by ntpd. That said, you could have both a timezone issue and an ntpd issue.

My ntpd service seems a little happier than yours:

Code: 
[user@freebsd ~]$ ntpstat
synchronised to NTP server (<redacted>) at stratum 2
   time correct to within 237 ms
   polling server every 1024 s
[user@freebsd ~]$ ntptime
ntp_gettime() returns code 0 (OK)
  time e6e4bd8d.fe191148  Mon, Oct  3 2022  1:46:53.992, (.992570123),
  maximum error 3729291 us, estimated error 2220 us, TAI offset 37
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 103.994 us, frequency 1.893 ppm, interval 4 s,
  maximum error 3729291 us, estimated error 2220 us,
  status 0x6001 (PLL,NANO,MODE),
  time constant 10, precision 0.001 us, tolerance 496 ppm,
  pps frequency 2.222 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
[user@freebsd ~]$ ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
<redacted>           1 u 129m 1024  200   44.392   +0.161   2.077

There's a write-up on Red Hat's support portal that discusses the ntp_gettime() returns code 5 (ERROR) you received, but it's behind a paywall. A post on a Ubuntu forum comes to a quick end when the OP reports the problem went away after a reboot.

Hate to ask, but what happens after you reboot the machine? There should be a message printed in the boot messages about ntpdate synchronising. You can view it with dmesg -a.

Also, have you tried setting the machine to a different timezone with tzsetup(), and is time off from what it should be then?
 
After deleting some unwanted dross, rebooting, being patient, etc, it all now seems to work out nicely.

Code: 
root@freebsd:/usr/home/user # echo "ntptime: " && ntptime && echo "ntpstat :" && ntpstat && echo "ntpq -p :" && ntpq -p && echo "date :" && date
ntptime: 
ntp_gettime() returns code 0 (OK)
  time e6e4da4e.b699d884  Mon, Oct  3 2022 14:49:34.713, (.713285542),
  maximum error 155411 us, estimated error 397 us, TAI offset 37
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 853.439 us, frequency 5.048 ppm, interval 4 s,
  maximum error 155411 us, estimated error 397 us,
  status 0x2001 (PLL,NANO),
  time constant 7, precision 0.001 us, tolerance 496 ppm,
  pps frequency 4.982 ppm, stability 0.000 ppm, jitter 0.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
ntpstat :
synchronised to NTP server (203.135.184.123) at stratum 2
   time correct to within 33 ms
   polling server every 256 s
ntpq -p :
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.freebsd.pool. .POOL.          16 p    -   64    0    0.000   +0.000   0.000
-ec2-13-55-50-68 203.206.205.83   3 u  217  512  377    5.818   +2.663   0.285
+ntp.seby.io     17.253.66.125    2 u  226  256  377    5.176   +0.867   0.263
-159.196.2.87 (1 45.76.113.31     3 u  241  512  377   21.513   +0.221   0.124
+103.76.40.123 ( 203.35.83.242    2 u  149  256  377    5.669   +0.882   0.270
*leontp.ccgs.wa. .GPS.            1 u   48   64  377   52.861   +1.258   0.056
date :
Mon  3 Oct 2022 14:49:34 AEDT

Thanks to all who helped.
 
You must log in or register to reply here.
Back
Top