Daylight saving time – how time is stored, how to change it

The why

Today at 2am, the time in New Zealand went ahead one hour. Spring is not far
away! I also noticed that my daily and weekly reports were not run as normal.
This led to start thinking about why and how this occurred.

As mentioned above, the time
went ahead one hour at 2am. So, in theory, the time between 02:00:00 and 02:59:59
did not occur. The reports in question run automatically at 2am. So I
concluded that the reason the reports didn’t run was because the time didn’t exist.
For my situation, that is OK. It may not be acceptable for a production
environment. And a similar problem will occur when the time goes back. I
initially thought the reports might be run twice but discarded that possibility for the
same reason that they were not run at all when the time went ahead. That is, they
weren’t run at 2am this time, why would they run when the time goes back at 2am?

I think that a possible solution would be to run the reports at some time outside the
1am to 3am timeslot. Say 3:01 which will always occur and will occur only once.

The how

FreeBSD does not use the BIOS of your computer (well, it might, for just a little
while when booting…). FreeBSD maintains a kernal clock, which is always set to UTC
(also known as Greenwich or Zulu time). The CMOS clock may be set to local
time. A utility (adjkerntz) is provided which maintains the proper
relations between these two times.

Changing the time

I have not tested the following steps. They have been retrieved from the mailing list archives.
Like everything on this website, use it at your own risk.

su to root
tzsetup
touch /etc/wall_cmos_clock (to make sure it’s synched)

You might also want to check out the man pages for adjkerntz.

Daylight saving time – how time is stored, how to change it