[SOLVED] System clock refuses to adopt my timezone

(Running ArchLinux in VMWare)
I'm trying to set my system clock to Europe/Lisbon unsuccessfully. I followed these steps:
Step 1. (rc.conf)
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Lisbon"
Step 2. (localtime)
$ rm /etc/localtime
$ ln -sf /us/share/zoneinfo/Europe/Lisbon /etc/localtime
Step 3. (reboot)
Result:
marfig@archway ~ $ date
Fri Aug 6 15:27:26 WEST 2010
marfig@archway ~ $ hwclock
Fri 06 Aug 2010 03:27:31 PM WEST -0.000409 seconds
Is there something wrong with /us/share/zoneinfo/Europe/Lisbon?
Last edited by marfig (2010-08-06 14:49:17)

marfig wrote:
No. The time is correct. The timezone isn't. Why is it displaying Western time? (WEST)
EDIT: gah! I'm so stupid. the simple fact I wrote this prompted me to search 'west timezone' in google. This Western European Time Summer Time. The timezone is correct and I'm a fool. So sorry for this useless thread.
You should add this to the Try This thread called the "dumbest mistake you made"
https://bbs.archlinux.org/viewtopic.php?id=11728
Last edited by Inxsible (2010-08-06 14:51:18)

Similar Messages

[SOLVED] System clock loses minutes at reboot

For some reason, my system clock (as displayed by date) loses around five minutes every time I reboot. When I use date -s to set the time manually everything's fine until reboot when the clock will lose around five minutes again. Even if I put the clock forward 10 minutes it will lose 5 minutes again after reboot. This happens even if there is no connection to any other clock. No ntpd installed.
How do I fix this (wthout ntpd)?
Last edited by itektur (2014-09-20 14:45:52)

Thank you for the quick reply. I set up systemd-timesyncd and it seems to work fine even after rebooting the system. Problem solved!

[SOLVED]System clock off

My system clock is set a day late. I tried using the "date" command, but I get the following error:
$ sudo date 06151150
sudo: timestamp too far in the future: Jun 16 11:37:36 2008
Here are the pertinent lines from my rc.conf:
LOCALE="en_US.utf8"
HARDWARECLOCK="UTC"
TIMEZONE="US/Eastern"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
Any help would be great!
Last edited by crisnoh (2008-06-15 16:31:35)

Hey, this seems to be a security feature of sudo, so if you can, run it as root instead.
There is a few solutions to the problem, one of which seems to be the one listed at here, where the solution just seems to be removing a simple file, but I have not tried it myself so dont know for sure.

[SOLVED] System Clock Issues (Wrong UTC?)

**RESOLVED -- SEE END FOR FIX
Hello everyone.
First off I'd like to say that I am thrilled to be here. I've been an Ubuntu user for a few months now, but decided that it was time to take a trip down the rabbit hole and see all that Linux had to offer--and to that end I switched to Arch. And I must say that I have nothing but positive things to say of it. The documentation on the Arch Wiki was phenomenal in helping me get started on the process, and the installation of it has proved to be a very enjoyable learning experience.
With that said, I have run into a bit of a snag, and after perusing the documentation on the Wiki, as well as running a few Google searches and searches of this particular forum, am no closer to a solution that when I started, so here I am. The problem is with my clock.
Okay, so I live in the Eastern United States, and as a result have my local time set as Eastern, and I have my hardware clock running UTC. Here is the problem. . . For whatever reason, the time displayed on my clock is five hours behind. Perplexed, I decided to see if I had set up my time zone info incorrectly and ran the "timedatectl status" command, and the results were really strange. A copy paste of the output is here:
Local time: Thu, 2012-12-20 19:27:02 EST
Universal time: Fri, 2012-12-21 00:27:02 UTC
RTC time: Fri, 2012-12-21 00:27:02
Timezone: America/New_York
UTC offset: -0500
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: no
Last DST change: EDT → EST, DST became inactive
Sun, 2012-11-04 01:59:59 EDT
Sun, 2012-11-04 01:00:00 EST
Next DST change: EST → EDT, DST will become active
the clock will jump one hour forward
Sun, 2013-03-10 01:59:59 EST
Sun, 2013-03-10 03:00:00 EDT
As you can see, the time zone is set correctly to America/New_York (originally US/Eastern, but I changed it to try and resolve the problem--to no effect, obviously). However here is where it gets strange. As I type this, it is 00:27 local time. My computer has decided to use the local time for UTC, and then subtracts five hours (as I live in UTC -5) to get the local time that it displays.
I've tried rerunning the hwclock --systohc --utc command, to no avail.
If anyone has any input as to why my computer is confusing UTC and local time, and any way I could fix it, I would greatly appreciate it.
I could just change my timezone to UTC - 0, that would cause my system to display the right time (I think) but I'd rather actually fix the problem, instead of simply covering it up with a band aid, if it is possible.
Thank you,
Douglas
EDIT:
I probably should mention that the machines (I'm having this same problem on two different computers) are both running Arch Linux and Arch Linux alone, although one was originally a Windows 7 and the other a dual boot of Win 7 and Ubuntu.
RESOLUTION (Thanks lhoffman):
Install the network time protocol daemon. This will allow you to sync your system time over the internet.
sudo pacman -S ntp
Once installed, run the following command:
ntpdate pool.ntp.org
This will link your computer with the time servers of the NTP Pool Project. For me my clocks fixed themselves quickly after running the command. And that was it.
After running this command and setting the system clock, run:
hwclock -systohc (thanks Scimmia)
Otherwise the computer will mistake local time for UTC and subtract/add time based upon your timezone again upon reboot.
Last edited by douglasr (2012-12-21 21:23:11)

Scimmia wrote:Not exactly. The root of the problem is that your hardware clock is set to localtime. To change this, you need to update the system (software) clock, which ntpd already did for you. The timedatectl command would have just done that manually. Now that your system clock is correct, you need to write this to your hardware clock so that it is correct when you reboot. hwclock --systohc does that. If you don't run that command, the system will boot up thinking it's getting UTC from the hardware clock and will subtract 5 hours. Then, once ntpd runs, the time will skip ahead 5 hours. This will cause all kinds of issues.
I fixed this on my system too. Thanks for the explanation.

(SOLVED) system time refuses to change

My hwclock is correct. However, --systohc doesn't work. I also tried ntp and openntpd and they don't help any either.
Has anyone had a super-stubborn system clock?
I have tried UTC, localtime and the whole shebang. I can make the system clock change if I alter my location but I don't want to spoof my location just to fix my time. My location is set correctly but my system clock is about 14 hours in the future.
Last edited by Google (2011-08-12 01:17:14)

hwclock from util-linux 2.19.1
Using /dev interface to clock.
Last drift adjustment done at 1313128033 seconds after 1969
Last calibration done at 1313128033 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2011/08/12 15:07:28
Hw clock time : 2011/08/12 15:07:28 = 1313129248 seconds since 1969
Fri 12 Aug 2011 03:07:28 PM KST -0.063131 seconds

[SOLVED] System clock / Timezone issues

Hey everyone,
The issue, as it appears to me, is that arch is assuming that my timezone is +00:00, or UTC. I don't really understand why (it should be +10:00) but here is the output to the frequently requested information for this issue
$ cat /etc/adjtime
0.000000 1349592374 0.000000
1349592374
UTC
$ date
Sun Oct 7 07:42:52 UTC 2012
$ date --utc
Sun Oct 7 07:43:18 UTC 2012
$ hwclock --debug
hwclock from util-linux 2.22
Using /dev interface to clock.
Last drift adjustment done at 1349592374 seconds after 1969
Last calibration done at 1349592374 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2012/10/07 07:43:54
Hw clock time : 2012/10/07 07:43:54 = 1349595834 seconds since 1969
Sun 07 Oct 2012 07:43:54 UTC -0.969672 seconds
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 37 Oct 7 06:39 /etc/localtime -> /usr/share/zoneinfo/Austalia/Brisbane
$ hwclock --show --utc
Sun 07 Oct 2012 07:44:53 UTC -0.687942 seconds
$ hwclock --show --localtime
Sun 07 Oct 2012 07:44:57 UTC -0.281630 seconds
I'm using sytemd, have no rc.conf file, my BIOS clock reported being in UTC. I've been trying to fix this issue for the past few hours (including searching the wiki entries for time, beginner's guide, systemd and many other user's issues related to the clocks/timezones.)
I hope it's just a case of I missed something crucial somehow. Any help is greatly aprpeciated
Last edited by hungryb (2012-10-07 08:40:58)

skunktrader wrote:You didn't need to reinstall tzdata. The reason for your error was a typo in the symlink
lrwxrwxrwx 1 root root 37 Oct 7 06:39 /etc/localtime -> /usr/share/zoneinfo/Austalia/Brisbane
Yeah, that's true, but I'd been remaking symlinks and changing the clock for a while before that iteration, I think it was only that version of the symlink that contained a spelling error.

Hardware clock and system clock don't match

hello. i recently upgraded to kde 4.7, and i don't know if it's the culprit or not, but my system clock is now ahead of the hardware clock by the timezone offset.
my timezone is Asia/Manila, which is UTC+8. so if the correct time is 00:00, the system time is 08:00.
i dual boot with windows so the HARDWARECLOCK setting in /etc/rc.conf is set to localtime.
interestingly, the commands "hwclock --show" and "date" both show PHT as the timezone, but with the aforementioned time skew. to illustrate:
# hwclock --show
Fri 05 Aug 2011 10:45:02 AM PHT -0.500309 seconds
# date
Fri Aug 5 18:45:02 PHT 2011
running "hwclock --hctosys" fixes the problem while logged in, but restarting the computer reverts the problem. i could put a daemon that runs the command at startup, but i never needed to do that before and i'm not inclined to at the moment. i think this is just a misconfiguration somewhere.
thanks for any help you could give.

hello. it is
hwclock from util-linux 2.19.1
Using /dev interface to clock.
Last drift adjustment done at 1312511647 seconds after 1969
Last calibration done at 1304274137 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2011/08/05 12:08:46
Hw clock time : 2011/08/05 12:08:46 = 1312517326 seconds since 1969
Fri 05 Aug 2011 12:08:46 PM PHT -0.690104 seconds

System clock fails to update after waking from sleep

I've noticed that my new PowerMac G5 Dual-Core 2GHz (running Mac OS X 10.4.3) doesn't update its system clock to the current time after waking from sleep.
When I put it to sleep and then wake it some time later, the Clock in the upper right-hand corner doesn't update to the current time. It still ticks on (second for second) but remains out of sync.
Opening the Date & Time preferences pane will restore the time to the correct setting.
This problem only occurs with sleep and then wake-from-sleep. It doesn't happen when I shut down the machine and then restart it.
Does anybody know if I've got a malfunctioning machine? It's only 1 day old...
Or better still, how do I solve this problem?
PowerMac G5 Dual-Core 2GHz Mac OS X (10.4.3)

No, my Mac is not having trouble contacting the time server. I checked the console log and found no messages related to this.
I am on a broadband always-on connection (recently switched from DSL to cable modem, and the problem occurred under both connections). However, my original post states that the computer loses time only when it is asleep, and I didn't think that my computer could contact the time server when it is asleep. It also loses time when it is off, which I neglected to mention previously. Am I mistaken in thinking that the computer communicates over the network only when it is awake? Since it keeps accurate time when awake (once I've reset it by opening the Date & Time control panel), it seems to me like it IS communicating with the time server without issue.
[And I apologize for misinterpreting your question as a suggestion. I was trying to be polite by thanking you for taking an interest in my issue. I'll watch my semantics more carefully next time.]
Cheers,
Katy
G5/dual core 2.3 Ghz Mac OS X (10.4.4) 2.5G RAM

Virtualized Arch (VirtualBox) - System clock is wrong..,

In my Arch Linux VM, my system clock is either 7 hours slow or 17 hours fast (can't tell the date on it...how do I make Fluxbox display the date with the time?). This may be a problem with Arch but it most likely is a VirtualBox issue. How can I change the system clock on V-box (if that's the issue) or how can I fix Arch?
This may be a timezone issue. I live in the US, but I set "Canada/Eastern" as the timezone. Shouldn't matter because I'm in the Eastern time zone but in the interest of full disclosure, I thought I'd mention it.
EDIT: May or may not be important: I'm using Virtualbox OSE, not the proprietary edition.
Last edited by sajro (2008-03-21 13:37:56)

As far as i'm aware, clocks in virtual systems are always wrong. I don't think it's to do with arch (although changing UTC to localtime or vice versa in rc.conf might have some effect), more to do with the timing of the CPU or something being slightly off for virtual machines due to the virtual nature of the system.

Howto set system clock with milliseconds precision

Hi! I need to set the system clock with milliseconds precision. The Labwindows CVI SetSystemTime function use only seconds precision. How to get around the problem?
Thanks in advice!
Solved!
Go to Solution.

I talked too early,
Actually I found that the SDK version of the SetSytemTime function does accept milliseconds.
However, its usage is a little different.
You need to create an object of type SYSTEMTIME and set its members to the values you need.
Then, call the SetSystemTime function (of the WinSDK) to set the clock.
You need to add "windows.h" to the top of your include list.
(see SDK help, there is a sample code available there)
Message Edited by ebalci on 01-04-2010 12:05 PM
S. Eren BALCI
www.aselsan.com.tr

HP DV3-2350el - system clock loses time

Hi,
I have a HP Pavilion DV3-2350el, just returned back from a repair by HP in warranty.
Now I've noticed that the system clock loses time when the notebook is off.
I think it should be a CMOS battery issue, but I haven't found any information about it.

Hi,
How old is your machine ? Normally a CMOS battery can last for 4 or 5 years. Anyway, you may want to try yourself or bring it back to the repairer to reseat the CMOS battery. You can download this manual, page 4-22 shows you how to work with the RTC (or CMOS) battery.
http://h10032.www1.hp.com/ctg/Manual/c01998025.pdf
Regards,
BH
**Click the KUDOS thumb up on the left to say 'Thanks'**
Make it easier for other people to find solutions by marking a Reply 'Accept as Solution' if it solves your problem.

Install changes system clock

how come when i install arch, and then boot into windows later, my system clock is changed to like 8 hours ago. has this happened to anyone before?

And what time is it really ?
What I would do now : decide for yourself if you want the CMOS clock in localtime or not. Your decision will probably depend on your Windows system. If you have WIndows98 (first edition) or earlier, you have no choice: CMOS should be localtime. If you have Win98SE or later then carefully check in your Windows system how you set it up. It *usually* wants it in localtime, but it can handle UTC, therefore check your configuration.
Now, you know how you want your CMOS/BIOS clock to be.
Now boot into Arch and edit /etc/rc.conf accordingly. Note, however that your TIMEZONE is incorrect. You probably want something like
TIMEZONE=America/New_York
TIMEZONE=EST
Note, that the first automatically switches between daylight savings time, whereas the second does not necessarily. The value you give to TIMEZONE has to actually exist as a file in /usr/share/zoneinfo/ (I.e. no matter weather you live in Boston, D.C., Miami, Atlanta, Philladelphia you always choose America/New_York) !
Now that you have edited /etc/rc.conf correctly, I would boot into the BIOS and set the CMOS clock there correctly.
EDIT: links to 2 previous threads about this topic :
http://bbs.archlinux.org/viewtopic.php?t=2198
http://bbs.archlinux.org/viewtopic.php?t=830

Standby Server System Clock

I have not seen any documentation that suggest Principal and Mirror Server system clock need to be synchronized for multi data center design with different time zone. Mirroring is not going to fail, but application can behave odd when a fail-over happen.
Is there any supporting document or article on this regard?

Hi,
You don't definitely need to sync clocks for server which are in different zones for mirroring. Mirroring is not affected by time as such. Since it involves transfer of logs from one system to other there is no relation to time. Plus mirroring is also not
affected by day light saving
I am not sure about article need to search. May be below articles interest you
http://www.sqlskills.com/blogs/paul/how-does-daylight-savings-time-affect-disaster-recovery/
https://technet.microsoft.com/en-us/magazine/2007.03.sqlqa.aspx
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My Technet Wiki Article
MVP

Is Mail.app one of the "erratic" behavior apps with a reset system clock?

I am hoping someone can help with a fine detail of mail.app (v2.1.3) behavior.
I had an incident where an iMac sent out 200+ smtp hits a minute and was tossed of the network for presumed zombie spaming.
I think I have actually tracked the problem to an unfortunate conjunction of circumstances that is actually innocent (if still annoying)
Let me set up the story:
1. This is a common use computer, so Mail is not configured (except that it is --I'll get to that in a moment) and
2. Safari will invoke Mail when you click on an "email link"
Mostly everyone just quits mail if they goof and click an email link.
BUT some time ago at least one person invoked Mail and composed a message. This message, naturally, remained in the outbox ever since. That person learned that they can't send email that way, so ever since they just cmd-Q Mail.
BUT Before this person learned, they walked through the mail-config and told mail to try hitting smtp.mac.com:"nonExistantUser".
So that covers the lead-up. Two days ago, mail was invoked via a Safari link, BUT it wasn't quit, it was sent to the background.
Where it undoubtedly tried to send the outbox repeatedly until it was kicked off the network.
Here is what I don't understand:
Under this scenario of a mis-configured .mac address, will mail repeatedly try and fail to smtp at the maximum possible rate?
OR
Is the one other factor I am about to describe responsible?
The one other factor:
The clock battery is dead and there was a power failure at 4am that day.
The system clock reset to 1969.
Of course, nobody reset it.
Is mail.app one of the apps that the finder message warns "may behave erratically"?
(a GROSS simplification) does it have a bit of code like:
1 check time-of-last-send-mail-attempt
check newest-item-in-outbox
if newest-item more recent then last-send-attempt
do send-mail and record time-of-last-send-mail-attempt
and go to 1
else wait X minutes and go to 1
which, if the clock was mis-set to 1969 would always record a last-send-attempt prior to anything in the outbox and trigger a send loop.
Does anyone know if either Mail is tenacious about sending to a bad .mac address, or gets ridiculous under this circumstance for bad-clock-set?
Marc

I am hoping someone can help with a fine detail of mail.app (v2.1.3) behavior.
I had an incident where an iMac sent out 200+ smtp hits a minute and was tossed of the network for presumed zombie spaming.
I think I have actually tracked the problem to an unfortunate conjunction of circumstances that is actually innocent (if still annoying)
Let me set up the story:
1. This is a common use computer, so Mail is not configured (except that it is --I'll get to that in a moment) and
2. Safari will invoke Mail when you click on an "email link"
Mostly everyone just quits mail if they goof and click an email link.
BUT some time ago at least one person invoked Mail and composed a message. This message, naturally, remained in the outbox ever since. That person learned that they can't send email that way, so ever since they just cmd-Q Mail.
BUT Before this person learned, they walked through the mail-config and told mail to try hitting smtp.mac.com:"nonExistantUser".
So that covers the lead-up. Two days ago, mail was invoked via a Safari link, BUT it wasn't quit, it was sent to the background.
Where it undoubtedly tried to send the outbox repeatedly until it was kicked off the network.
Here is what I don't understand:
Under this scenario of a mis-configured .mac address, will mail repeatedly try and fail to smtp at the maximum possible rate?
OR
Is the one other factor I am about to describe responsible?
The one other factor:
The clock battery is dead and there was a power failure at 4am that day.
The system clock reset to 1969.
Of course, nobody reset it.
Is mail.app one of the apps that the finder message warns "may behave erratically"?
(a GROSS simplification) does it have a bit of code like:
1 check time-of-last-send-mail-attempt
check newest-item-in-outbox
if newest-item more recent then last-send-attempt
do send-mail and record time-of-last-send-mail-attempt
and go to 1
else wait X minutes and go to 1
which, if the clock was mis-set to 1969 would always record a last-send-attempt prior to anything in the outbox and trigger a send loop.
Does anyone know if either Mail is tenacious about sending to a bad .mac address, or gets ridiculous under this circumstance for bad-clock-set?
Marc

ICal, Mail and Finder times all stuck since upgrade! System clock O.K.

Very strange problem:
All of my calendar event times (in iCal), email message receipt times (in Mail), and file modification/creation times (in Finder) are listed as some time between 7:00-7:59 AM or PM, regardless of time of day! My system clock (as it appears in the menu bar) is fine!
More details:
iCal: the events still look like they're at the right times, i.e. the blocks are in the right places, with the correct spacing, etc etc, they are just labeled with times between 7:00-7:59 AM/PM. Similarly, alarms go off at the correct time. Also, in the day or week listing, the column on the left which is supposed to show times instead just says "Sat" for all times, except "Noon" (at noon).
This is continuous since upgrading to snow leopard a couple weeks ago. Seemingly no other problems besides this.
I don't know much about the OS, but I don't understand how the system clock (in the menu bar) could be fine, but every other sign of time-keeping is completely off. I just its just something about the labeling of times, instead of the actual record of them?!
I have screen shots of the problems if that might help clarify (apparently I can't attach them however).
Thanks for your help!

Hi,
Any solutions to your problems?
Just found my Mom has the same 'time stuck' problem (iMac OS X 10.6.7) Finder 'Date Modified' is stuck at 2/14/2011. Also, the Time/Date displays correctly on the Menu bar but when click on it, the drop down menu shows a gray out 2/14/2011, etc.
Much appreciated of any help. Thx.
-MasterMoo

[SOLVED] System clock refuses to adopt my timezone

Similar Messages

Maybe you are looking for