Re: [9fans] Date woes

[Bakul Shah <bakul@bitblocks.com>]

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.