[9fans] Date woes

[t***@polynum.com]

I was testing a new version of kerTeX (more changes to my compilation
framework---mainly around Windows Interix support) with Plan9 (new
version released BTW), and I stumbled once upon on date strange
behavior.

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).

What I don't get:

1) How can fossil and the system display two different dates? Are they
not using the very same system value?

2) Could it be that fossil takes CMOS and then continue on its own or
takes CMOS constantly, while the kernel (?) takes CMOS, then leaves it
alone, correct (wrongly) and counts in software, overwriting the value
only when rebooting?

3) Is there something related to Windows "compatibility"? I mean,
Windows stores (stored) local time, and is there a variable that
instructs to correct the CMOS value?

Thanks for clues!

[erik quanstrom]

Post by t***@polynum.com
1) How can fossil and the system display two different dates? Are they
not using the very same system value?
2) Could it be that fossil takes CMOS and then continue on its own or
takes CMOS constantly, while the kernel (?) takes CMOS, then leaves it
alone, correct (wrongly) and counts in software, overwriting the value
only when rebooting?
3) Is there something related to Windows "compatibility"? I mean,
Windows stores (stored) local time, and is there a variable that
instructs to correct the CMOS value?

1. check your $timezone environment variable. it could be they
are different for fossil and the shell. $timezone is in /env, and there
is an independent /env for each process group, so it is entirely
possible to have many values on the same system.

3. i think timesync(8) may have the information you're looking for.

- erik

[t***@polynum.com]

Post by erik quanstrom
is an independent /env for each process group, so it is entirely
possible to have many values on the same system.

But this may affect the way the date is displayed, not the UTC?

Post by erik quanstrom
3. i think timesync(8) may have the information you're looking for.

Thanks for the tip. I have added it to my profile.

I have read too rtc(3) and cons(3).

And I wonder if somewhere I have a:

cat /dev/rtc >/dev/time

because it seems that it uses timezone in between to convert the value
passed according to the timezone, hence, with an rtc in UTC, it
substracts 7200 according to my CEST timezone...

[erik quanstrom]

Post by t***@polynum.com
But this may affect the way the date is displayed, not the UTC?

are you sure it's not a display issue? sometimes a double-timezone
conversion or incorrect timezone conversion can screw up the date.
fossil uses time(0), which in theory should not conflict.

Post by t***@polynum.com

Post by erik quanstrom
3. i think timesync(8) may have the information you're looking for.

Thanks for the tip. I have added it to my profile.

make sure you don't have two timesyncs running! there
may be one in /rc/bin/termrc or /rc/bin/cpurc. two at war
can be a fatal problem.

- erik

[t***@polynum.com]

Post by erik quanstrom

Post by t***@polynum.com
But this may affect the way the date is displayed, not the UTC?

are you sure it's not a display issue? sometimes a double-timezone
conversion or incorrect timezone conversion can screw up the date.
fossil uses time(0), which in theory should not conflict.

But it is incorrectly setting rtc on exit to the wrong value. So this is
not a display problem. One "time" has the wrong value, /dev/rtc has the
right (until reboot, because wrong is stored---I verified in the BIOS),
and fileserver /dev/time has the wrong.

Post by erik quanstrom

Post by t***@polynum.com

Post by erik quanstrom
3. i think timesync(8) may have the information you're looking for.

Thanks for the tip. I have added it to my profile.

make sure you don't have two timesyncs running! there
may be one in /rc/bin/termrc or /rc/bin/cpurc. two at war
can be a fatal problem.

I will revue all the scripts till my profile to try to understand what's
going on.

Thanks for the advices!

[erik quanstrom]

Post by t***@polynum.com

Post by erik quanstrom

Post by t***@polynum.com
But this may affect the way the date is displayed, not the UTC?

are you sure it's not a display issue? sometimes a double-timezone
conversion or incorrect timezone conversion can screw up the date.
fossil uses time(0), which in theory should not conflict.

But it is incorrectly setting rtc on exit to the wrong value. So this is
not a display problem. One "time" has the wrong value, /dev/rtc has the
right (until reboot, because wrong is stored---I verified in the BIOS),
and fileserver /dev/time has the wrong.

are you sure that these flags might not be part of the problem?
there is no clear answer to the question, "is rtc clock in local time
or gmt?"

-r synchronize to the local real time clock, #r/rtc.

-L used with -r to indicate the real time clock is in
local time rather than GMT. This is useful on PCs that
also run the Windows OS.

- erik

[t***@polynum.com]

Post by erik quanstrom
are you sure that these flags might not be part of the problem?
there is no clear answer to the question, "is rtc clock in local time
or gmt?"
-r synchronize to the local real time clock, #r/rtc.
-L used with -r to indicate the real time clock is in
local time rather than GMT. This is useful on PCs that
also run the Windows OS.

Found! In termrc:

TIMESYNCARGS=(-rLa1000000)


I guess this is a default what we should document somewhere. Or,
reversely, do not make it a default, and document how to change if
local time is stored.

Something still not clear: date (shell) was using the incorrect time
(local when RTC was in UTC), but fileserver was using correct that is
fileserver took the rtc but did not apply what aux/timesync applies.
Because fossil is mounted _before_ since termrc is served by fossil?

[Bakul Shah]

Post by t***@polynum.com
IIRC, I did not use this Plan9 node since the CET Saving Time switch.
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.

[t***@polynum.com]

Post by Bakul Shah
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.

Yes... But I have no Windows (except an XP _home_ sold with my old
laptop) so the RTC was in UTC. But termrc was timesync'ing with
"-L"---and I don't thing I even deal with this, since I played with a
total re-install when finding how to install Plan9 without a CD reader
or network (installing it from another OS already installed on the
disk).

What I still don't get is precisely how the fileserver could have the
right time, when the date displayed by the shell was wrong. It they both
use the same source (the kernel) how can this happen? Except that termrc
hence timesync(8) is run after the fileserver are launched, and then
are taking rtc but correcting it with the timezone (and perhaps the -L),
meaning that the fileserver will always use the time served by the
kernel from the RTC as UTC, while later program will use an user
specification to interpret the RTC.

The "-L" is a Windows thing but is in userland modifying a value that is
taken as is before userland is run...

[t***@polynum.com]

Post by t***@polynum.com
are taking rtc but correcting it with the timezone (and perhaps the -L),

Correction: if "-L", the userland parameter timezone is taken to correct
the RTC value. It seems that there is a hiatus (the reason why it was
precisely pure nonsense for some system to store local time i.e.
something totally user dependent and without any mean to interpret it
without this missing information).