When the time zone switches from Daylight Saving Time to Standard Time and back the system clock changes the time zone automatically (between MST and MDT: I'm in the Mountainous time zone) but doesn't change the hour. I wrote a script that adds/subtracts an hour. If I'm connected to the Internet (I'm not at home) the script I use to fetch the time will correct it. What's wrong?

RandomTroll,

Not knowing all the details of your situation, I have to ask, are you new to the Mountain time zone? I ask because, since I've not only dealt with time zone issues from that area of the US before, but I know people who live in that time zone, and is my distinct understanding, that only a couple of areas in Mountain time zone, don't actually change the time. So just to be sure, you are definitely in an area that does change the time, yes?

Also, a while back, the point during the year when the "Daylight Savings" time occurs was changed, so are you sure that your system software is new enough, or properly patched, so that it has a consistent idea of when the "Daylight Savings" time starts?

Finally, you mentioned you have something that fetches the time, so how does that interact with the system's own idea of time? Are you saying that you are using NTP, or something you've written yourself?

In general, more details please.

I have been in the Mountain TZ for 9 years. I live in New Mexico, which observes Daylight Saving Time, as does every other state in the region except Arizona. That 'date' returns MDT as the TZ at the correct time witnesses that my system software is up-to-date: I update it daily, so this doesn't surprise.

I use a time-setting program provided by NIST patched to set the system clock rather than adjtime.

RandomTroll,

Sorry, I did not mean to be confusing. I was obviously in too much of a hurry, I see I left out the all important word "don't"! So I stated the opposite of what I intended as the "exclusion clause" about Mountain time. I've edited my previous message to hopefully correct the confusion I caused. Since I have friends and relatives that live in Arizona, I'm aware of the difference with Arizona, as well as that there are exceptions; there are some areas within Arizona that choose not to honor the Arizona State "time zone" policy.

But to get more into the specifics of your time issue, when I use a laptop, in a situation where I don't have Internet access, but I wish to update the time, sometimes if I just set the time, I do not use adjtime either ( or anything that effectively would call adjtime ). Sometimes, it can still take quite a while before the time is actually updated.

In your situation, does the hour not update, no matter how long you wait? Are you using something like hwclock? If you reboot, is the hour then correct after the reboot?

Has this situation always existed with your machine, or only after some change to the system, for example, after some update was applied to the system?

If I understand you correctly, you make mention of using the script to correct the problem when you are connected to the Internet, while not at home. Does the correction not work at home? Or is there no Internet access at home?

Can you post the program from NIST you are using?

The problem is pretty much unavoidable if you have the hardware clock configured to read local time. If you shut the system down before the change to DST, the hardware clock will be set to the correct standard time. If you next start the system after the DST change, the hardware clock is now 1 hour slow, but the kernel will believe it is correct local time.

The fix is to keep the hardware clock set to UTC, though that can be a problem in a dual boot system that also runs MS Windows, at least until Microsoft finally works all the bugs out of keeping a UTC hardware clock.

I keep the hardware clock in UTC. After DST and ST switch 'date +%Z%z' reports the correct TZ. For the purposes of zoneinfo there are different zones for Arizona, the rest of MT, Navajo (the Navajo nation in Arizona keeps DST), and a couple of other non-standard users of MT. How can 'date' not report the correct local time when it has the correct time zone and should have the correct UTC? Nothing changes the hardware clock other than a program I run that fetches the correct time from an NIST-approved server and I only run that when I have an Internet connection. (And when I change it on purpose, as I do with AddHour and SubtractHour to deal with this event.) I'm unhappy that the city council has split our city into separate broadband provider zones so that each has a monopoly thus charges a monopoly price, why I don't pay for Internet connection at home.

When "date" is reporting the wrong local time, does "date -u" report the correct UTC time and does "hwclock -r" report the correct local time?

What is in your /etc/adjtime ?

If the file /etc/adjtime does not exist, then the hardware clock is assumed to be kept in local time.

1 members found this post helpful.

/etc/adjtime:

0.512434 1363196416 0.000000
1363196416
LOCAL

Hmmmm... I just inspected /proc/driver/rtc it has local time. How did that happen? How do I change that? adjtimex -u didn't seem to change anything. I set whether to keep the hardware clock in UTC or local when I install, which I haven't done in years.

timeconfig sets UTC/LOCAL; /etc/adjtime's last parameter so indicates. Somehow this slipped away from me without me noticing. Thanks to rknichols for the prompt that sent me to the right place to figure it out.

Just run "hwclock --systohc --utc" and it will set the clock to UTC and change /etc/adjtime so that UTC will be the default in the future.

I happen to live in Arizona. Arizona has no spring-ahead fall-back. It is always UTC-7. For reasons which remain mysterious, my computer started using UTC. This bizarre behavior made a mess of my log files. Log entries started showing up in the future; my drive partitions were last used in the future. I gave no one permission to change my system clock to UTC, so I suspect a rootkit got past the moat. Thanks for posting the spells I need to cast to restore order.

I repeat: Arizona does not need or use daylight savings time. A long, long, time ago, drive-in theaters couldn't start their programs until 9:30pm. I've heard of other strange places that also do not use daylight savings time. I get the impression from the image at https://en.wikipedia.org/wiki/Daylight_saving_time that most of the world does not use daylight savings time.