From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Tue, 23 Apr 2013 15:30:03 +0200." <20130423133003.GB19997@polynum.com> References: <20130423133003.GB19997@polynum.com> Date: Tue, 23 Apr 2013 14:55:32 -0700 From: Bakul Shah Message-Id: <20130423215532.7D855B82A@mail.bitblocks.com> Subject: Re: [9fans] Date woes Topicbox-Message-UUID: 476fecd0-ead8-11e9-9d60-3106f5b1d025 On Tue, 23 Apr 2013 15:30:03 +0200 tlaronde@polynum.com wrote: > IIRC, I did not use this Plan9 node since the CET Saving Time switch. > > When verifying a directory listing (fossil) I saw: > > The correct date (time) on the file (I mean the correct time in CEST). > > An incorrect time on the command line: it was 2 hours _backward_. And > when rebooting, the CMOS was being reset with this 2 hours error (from > UTC). setrtc just copies the first number from /dev/time (in UTC) to RTC. This is obviously wrong if your RTC maintains localtime. But RTC is just a dumb oscillator so it can't adjust for daylight saving time. My guess as to what must be happening: If you did fshalt prior to DST and your localtime is an hour ahead of UTC, setrtc introduces an error of one hour. So for example, on the day before DST switchover, when local time is 8pm, rtc will show 7pm. Now 24 hours later local time is 9pm due to daylight saving but rtc will still show 7pm. Now timesync with -rL will assume this is correct and proceed to make a two hour "correction". The filesystem stores timestamps in UTC and it just believes whatever the kernel tells it. As it should. Just use TIMESYNCARGS-(-n pool.ntp.org) or some such. Finally if you are running Windows 7 *and* have a recent hotfix 2800213 installed, you *can* use UTC in RTC by registry entry RealTimeIsUniversal=1. Or so I am told! Finally, 20+ years later, microsoft does the right thing when they could've fixed this in 3.1.