[SOLVED] The system time switches the time zone automatically but doesn't change the time
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The system time switches the time zone automatically but doesn't change the time
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?
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.
Last edited by rigor; 03-11-2013 at 05:17 PM.
Reason: Left out the word "don't", reversing the intent of my comment on Mountain time.
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.
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?
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.
Last edited by RandomTroll; 03-12-2013 at 02:37 PM.
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.
Last edited by RandomTroll; 03-13-2013 at 02:25 PM.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.