You are not logged in.
arch is showing incorrect time. For example, it shows 15h and it should be 13h. Anyway if I boot into Win8, it shows correct time. Also, if I set correct time in arch and I reboot, arch linux is showing the correct time once boot but not Win8. So, is there a way to set the time correctly independently of the OS? I want that the time be correctly shown independently if I boot into arch or win8.
Both OSes are set to use UTC.
I am using old initscripts, /etc/rc.conf:
DAEMON_LOCALE="no"
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Madrid"
and hwclock in daemons.
Currently using kernel 3.8.8-2-ARCH
Thanks in advance.
Last edited by toni (2013-04-29 20:58:39)
Offline
It makes sense to disable time synchronization in Windows - otherwise it will mess up the hardware clock.
Worked for me, with win7.
If that’s not it, maybe cheating with the timezone?
Last edited by cdrc (2013-04-29 12:21:33)
Offline
Use ntpd. But I am not sure if ntpd still has rc.conf compatibility. I suggest you to migrate to systemd.
Never argue with stupid people,They will drag you down to their level and then beat you with experience.--Mark Twain
@github
Offline
Your hardware clock should be set to UTC (continental European summer time minus 2 hours). Set it using BIOS setup and then check which OS shows correct time and fix the other one. Considering that Arch shows 2 hours later than Windows, it's probably Windows that's broken.
Offline
Your hardware clock should be set to UTC (continental European summer time minus 2 hours). Set it using BIOS setup and then check which OS shows correct time and fix the other one. Considering that Arch shows 2 hours later than Windows, it's probably Windows that's broken.
I have set my hardware clock correctly in BIOS and then I perform following steps depending on scenario:
Scenario #1 Booting into Win8
1.- I check out the clock in BIOS to see that is correct previous to boot into Win8
2.- I boot into Win8 and I see that clock is correct
Scenario #2 Booting into arch
1.- I check out the clock in BIOS to see that is correct previous to boot into arch
2.- I boot into arch and I see that clock is incorrect +2 hours
so I think there is a problem in my arch linux, maybe something not configured correctly. Acrch show 2 hours later than W**** but W**** is showing the correct one so the issue is related to arch.
If I executed "timedatectl status" it outputs below information. The correct hour is shown by UTC, so why arch is not showing it? and why is showing the incorrect one (local time) instead?
Local time: lun 2013-04-29 22:13:57 CEST
Universal time: lun 2013-04-29 20:13:57 UTC
RTC time: lun 2013-04-29 20:13:57
Timezone: Europe/Madrid (CEST, +0200)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
dom 2013-03-31 01:59:59 CET
dom 2013-03-31 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
dom 2013-10-27 02:59:59 CEST
dom 2013-10-27 02:00:00 CET
Last edited by toni (2013-04-29 18:19:44)
Offline
so I think there is a problem in my arch linux
yes, there is, it's the fact that you are still using initscripts. Not saying that initscripts is definitively at fault here, but you can't really expect much help here if you still use an init system that has been deprecated for 6 months.
Offline
Windows expects the clock to be set to local time. Generally, Linux expects the clock to be set to UTC.
I check out the clock in BIOS to see that is correct previous to boot into Win8/arch
If you mean the clock is always the correct *local* time, then that explains why Windows time is correct and Arch time is not. You need to decide how to harmonize the conflicting expectations of the two OSs.
toni wrote:so I think there is a problem in my arch linux
yes, there is, it's the fact that you are still using initscripts. Not saying that initscripts is definitively at fault here, but you can't really expect much help here if you still use an init system that has been deprecated for 6 months.
Also this.
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Almost all serious operating systems assume that the BIOS clock is set to UTC. A certain popular operating system that, (originally) was not designed to connect to the internet, assumes that the BIOS clock is set to local time. This creates havoc whenever governments arbitrarily add seasonal offsets to local time, or when a system moves from one timezone to another.
When you say the clock in BIOS is correct, does it reflect your local time, or is it set to UTC ?(as it should be)
Edit snaked by one minute by alphaniner
Last edited by ewaller (2013-04-29 21:57:57)
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
If I executed "timedatectl status" it outputs below information. The correct hour is shown by UTC, so why arch is not showing it? and why is showing the incorrect one (local time) instead?
So your hardware clock is in localtime, yet you're specifically telling Arch that it's UTC. Read your first post.
Offline
toni wrote:so I think there is a problem in my arch linux
yes, there is, it's the fact that you are still using initscripts. Not saying that initscripts is definitively at fault here, but you can't really expect much help here if you still use an init system that has been deprecated for 6 months.
Some days ago I decided to migrate all the initscripts to systemd, so this is what I did, but only a few ones still remain using initscripts, and they are the following in /etc/rc.conf because I have not found any equivalence in systemd:
DAEMONS=(hwclock hal netfs)
Regarding to hwclock I have read in arch wiki that it is no longer used by systemd (it is not necessary) so I wonder If I can remove from daemons. Can I remove hwclock from daemons? If I remove it, is it necessary to do something else?
Regarding to the other (hal, netfs) what are the equivalence in systemd? I know I should open another thread but as we are talking about it....
Thanks.
Offline
I have found that having the correct time can be problematic in some cases. As previously stated you are supposed to use localtime and not utc on the gnu/linux side if you dual boot with windows. The solution for me (I never found the daemon initscript or .service file to be completely reliable) was this: Install ntp / ntpq package(s). Make sure the time servers are correct in /etc/ntp.conf Here is an example (mine):
# Associate to public NTP pool servers; see http://www.pool.ntp.org/
server 0.us.pool.ntp.org
server 1.us.pool.ntp.org
server 2.us.pool.ntp.org
After that either set your /etc/rc.local or a .service file or add /usr/bin/ntpd to your sudo exceptions and setup something like this in your startup:
sleep 30 && /usr/bin/ntpd -qg &
or from a regular user startup script if you added it to your sudoers as an exception:
sleep 30 && sudo /usr/bin/ntpd -qg &
This is the only way I found for it to always work for me. The startup daemon or service may be better now but I will probably continue to do it this way.
Last edited by dodo3773 (2013-04-29 18:41:36)
Offline
If I executed "timedatectl status" it outputs below information. The correct hour is shown by UTC, so why arch is not showing it? and why is showing the incorrect one (local time) instead?
Local time: lun 2013-04-29 22:13:57 CEST Universal time: lun 2013-04-29 20:13:57 UTC RTC time: lun 2013-04-29 20:13:57 Timezone: Europe/Madrid (CEST, +0200)
Your Arch configuration is correct. You don't need to mess with rc.conf, init scripts, ntpd or anything else.
Your RTC needs to be set to UTC, not CEST. Adjust it by -2 and fix Windows.
Last edited by mich41 (2013-04-29 18:50:11)
Offline
Regarding to hwclock I have read in arch wiki that it is no longer used by systemd (it is not necessary) so I wonder If I can remove from daemons. Can I remove hwclock from daemons? If I remove it, is it necessary to do something else?
You just need to set your configuration files up like you would in any install. Instructions here: https://wiki.archlinux.org/index.php/Be … ase_system
Regarding to the other (hal, netfs) what are the equivalence in systemd? I know I should open another thread but as we are talking about it....
Are you actually using hal? It's been gone from Arch for a long time now (couple of years?).
netfs is handled automatically by systemd.
Offline
Are you actually using hal? It's been gone from Arch for a long time now (couple of years?).
Question is, are you using Arch or a derivative of Arch ?
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Scimmia wrote:Are you actually using hal? It's been gone from Arch for a long time now (couple of years?).
Question is, are you using Arch or a derivative of Arch ?
I am using original Arch. Not derivative.
Offline
toni wrote:Regarding to hwclock I have read in arch wiki that it is no longer used by systemd (it is not necessary) so I wonder If I can remove from daemons. Can I remove hwclock from daemons? If I remove it, is it necessary to do something else?
You just need to set your configuration files up like you would in any install. Instructions here: https://wiki.archlinux.org/index.php/Be … ase_system
toni wrote:Regarding to the other (hal, netfs) what are the equivalence in systemd? I know I should open another thread but as we are talking about it....
Are you actually using hal? It's been gone from Arch for a long time now (couple of years?).
netfs is handled automatically by systemd.
I have removed DAEMONS line from /etc/rc.conf and all continue working ok, so no hwclock, hal, netfs being used. Now they are completely migrated to systemd.
Offline
toni wrote:If I executed "timedatectl status" it outputs below information. The correct hour is shown by UTC, so why arch is not showing it? and why is showing the incorrect one (local time) instead?
Local time: lun 2013-04-29 22:13:57 CEST Universal time: lun 2013-04-29 20:13:57 UTC RTC time: lun 2013-04-29 20:13:57 Timezone: Europe/Madrid (CEST, +0200)
Your Arch configuration is correct. You don't need to mess with rc.conf, init scripts, ntpd or anything else.
Your RTC needs to be set to UTC, not CEST. Adjust it by -2 and fix Windows.
By RTC I understand the Real TIme Clock, that is, CMOS clock (that appears in BIOS). My RTC (from BIOS) is set to UTC, but once Arch boots it shows the local time CEST and I want to be shown the UTC which is the correct right now.
When you say my RTC needs to be set to UTC, I understand that below steps should be performed:
1.- Enter in BIOS
2.- Set the correct time in BIOS (the UTC time)
3.- Save changes
and finally boot up arch. Am I right? If not, could you please indicate me how to do it?
Thanks in advance.
Last edited by toni (2013-04-29 19:40:19)
Offline
When you say my RTC needs to be set to UTC, I understand that below steps should be performed:
1.- Enter in BIOS
2.- Set the correct time in BIOS (the UTC time)
3.- Save changesand finally boot up arch. Am I right? If not, could you please indicate me how to do it?
Thanks in advance.
Yes, that is how you do it, but:
My RTC (from BIOS) is set to UTC, but once Arch boots it shows the local time CEST and I want to be shown the UTC which is the correct right now.
Is completely wrong. First, from what I can tell, your RTC is not set to UTC like you seem think it is, it's set to CEST. Second, you do not want linux to show UTC, you want the RTC to be the correct UTC, so that when linux applies the timezone correction, you end up with the correct CEST.
Note that in this configuration, you need to make a registry change in Windows so that it knows that the clock is UTC.
Last edited by Scimmia (2013-04-29 19:54:44)
Offline
Can you please post the output of hwclock --debug ??
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
but once Arch boots it shows the local time CEST and I want to be shown the UTC which is the correct right now.
So you want your local time to display time for a different timezone? Then set your timezone to somewhere equivalent to UTC. You've set your time zone to CEST, and you are suprised that your time is displayed in CEST??
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
toni wrote:When you say my RTC needs to be set to UTC, I understand that below steps should be performed:
1.- Enter in BIOS
2.- Set the correct time in BIOS (the UTC time)
3.- Save changesand finally boot up arch. Am I right? If not, could you please indicate me how to do it?
Thanks in advance.
Yes, that is how you do it, but:
toni wrote:My RTC (from BIOS) is set to UTC, but once Arch boots it shows the local time CEST and I want to be shown the UTC which is the correct right now.
Is completely wrong. First, from what I can tell, your RTC is not set to UTC like you seem think it is, it's set to CEST. Second, you do not want linux to show UTC, you want the RTC to be the correct UTC, so that when linux applies the timezone correction, you end up with the correct CEST.
Note that in this configuration, you need to make a registry change in Windows so that it knows that the clock is UTC.
FInally I have solved by setting RTC in BIOS to -2 hours and creating the following registry key in Windows to indicate it is UTC:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
“RealTimeIsUniversal”=dword:00000001
so now it is working in dual boot, both OSes are shown the correct time right now because both are guessing that RTC is configured in UTC.
The output for "timedatectl status" is:
Local time: lun 2013-04-29 22:31:21 CEST
Universal time: lun 2013-04-29 20:31:21 UTC
RTC time: lun 2013-04-29 20:31:21
Timezone: Europe/Madrid (CEST, +0200)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
dom 2013-03-31 01:59:59 CET
dom 2013-03-31 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
dom 2013-10-27 02:59:59 CEST
dom 2013-10-27 02:00:00 CET
As I understand and after reading a lot of wikis, the problem was that arch (and linux distros and like MacOS) by default takes RTC as UTC and Win OSes as Localtime. So there are two options to solve it as I understand when dual boot is used:
1) Set RTC (hardware clock in BIOS) in localtime so it implies to tell linux it is set as local by doing "timedatectl set-local-rtc 1" and leave WIndows untouched as by default it suppose RTC is in Local and no need to create any registry key as above indicated.
2) Set RTC in UTC, in my case -2 hours, so it implies to leave linux untouched as by default linux interprets that RTC is in UTC, and to do some modifications in Windows, that is, create a registry key like above commented in order to indicate Windows that RTC has to be taken into account as UTC. CAUTION!!!! -> THIS METHOD IS NOT VALID AND NOT RECOMMENDED FOR Windows Server 2008, Windows 7, and Windows Server 2008 R2 (See this link for more details and also what David Batson says in the post below: http://support.microsoft.com/kb/2687252).
In my case I have choosen option 2.
Thanks all for your support.
Last edited by toni (2013-05-05 09:20:34)
Offline
*headdesk*
Yes, those are the very same options in the wiki and the ones you missed in many recommendations in this thread as you insisted your hwclock was in UTC, which apparently it was not.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
FInally I have solved by setting RTC in BIOS to -2 hours and creating the following registry key in Windows to indicate it is UTC:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] “RealTimeIsUniversal”=dword:00000001
so now it is working in dual boot, both OSes are shown the correct time right now because both are guessing that RTC is configured in UTC.
The output for "timedatectl status" is:
Local time: lun 2013-04-29 22:31:21 CEST Universal time: lun 2013-04-29 20:31:21 UTC RTC time: lun 2013-04-29 20:31:21 Timezone: Europe/Madrid (CEST, +0200) NTP enabled: n/a NTP synchronized: no RTC in local TZ: no DST active: yes Last DST change: DST began at dom 2013-03-31 01:59:59 CET dom 2013-03-31 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at dom 2013-10-27 02:59:59 CEST dom 2013-10-27 02:00:00 CET
As I understand and after reading a lot of wikis, the problem was that arch (and linux distros and like MacOS) by default takes RTC as UTC and Win OSes as Localtime. So there are two options to solve it as I understand when dual boot is used:
1) Set RTC (hardware clock in BIOS) in localtime so it implies to tell linux it is set as local by doing "timedatectl set-local-rtc 1" and leave WIndows untouched as by default it suppose RTC is in Local and no need to create any registry key as above indicated.
2) Set RTC in UTC, in my case -2 hours, so it implies to leave linux untouched as by default linux interprets that RTC is in UTC, and to do some modifications in Windows, that is, create a registry key like above commented in order to indicate Windows that RTC has to be taken into account as UTC.
In my case I have choosen option 2.
Thanks all for your support.
I have a similar setup with Archlinux, Fedora, Mageia, and Windows 7. I used the registry fix in Windows 7 and it seemed to go alright.
I also have a second hard disk that I sometimes use with this laptop through an expansion bay. This second hard drive has Bodhi Linux and Windows 8. While researching to see if I could use this registry fix in Windows 8, I read that either it does not work, or causes problems. The Archwiki on Time states (regarding this registry fix): "Note: The following method is not supported in Windows 8 and Windows Server 2012. Your only current option is to use localtime instead of UTC, as described above."
https://wiki.archlinux.org/index.php/Ti … in_Windows
Furthermore, I ran across the following information regarding Windows 7 and that registry hack.
Symptoms
Microsoft is aware of a potential system unresponsiveness issue that may be caused by using the RealTimeIsUniversal registry entry for the Daylight Saving Time (DST) changeover.Resolution
A hotfix is available to resolve this issue in Windows Server 2008, Windows 7, and Windows Server 2008 R2. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
2800213 High CPU usage during DST changeover in Windows Server 2008, Windows 7, or Windows Server 2008 R2
We strongly recommend that you not use the RealTimeIsUniversal registry entry. This issue does not occur if you do not use this entry.We recommend that you remove the RealTimeIsUniversal value from the registry or set its value to 0. This will prevent the system from becoming unresponsive during the DST changeover.
In light of this, I plan to have my Linux distros use local time instead of UTC time as in Option 1 above.
http://support.microsoft.com/kb/2687252
EDIT2: Nevermind. Previous edit had incorrect info.
Last edited by David Batson (2013-05-05 09:09:39)
Offline
In light of this, I plan to have my Linux distros use local time instead of UTC time as in Option 1 above.
http://support.microsoft.com/kb/2687252
Good job David! I have corrected the information posted in post 2 by putting a warning for those OSes.
Anyway, if you choose option 1), the issue posted originally for Win8 is not solved and doing this arch linux does not change automatically to the correct hour when necessary (Your clock will not be adjusted automatically for DST if your hwclock is not set to use UTC.) so as I understand there is no solution in this case, right?
Offline
Well, I've got all my OS's showing the current local time on their relevant clock applets. The BIOS hardware clock is set to local time. Not sure how DST will be affected when the time changes.
Offline