Computer time incorrect?

[jur]

Code: [Select]

tc@box:~$ showbootcodes
quiet tce=sda7 opt=sda7 home=sda7 max_loop=255 tz=EST,M10.1.0/2,M4.1.0/2 noicons
This morning I expected my computer time to revert back to winter time, but it didn't. Possible bug? Or does the hour 2am refer to UST instead of local time which is EST?

[maro]

That's interesting, I'd like to offer my thoughts:

(1) My guess is that: (a) you are located in eastern Australia, and (b) your HW clock is running on local time, which the "default" for systems also used to boot a Micro$oft OS.

(2) Your TZ variable differs from what one would expect for your (assumed) location. As reference I'm using a file provided by the 'tzdata.tcz' extension:
    tc@box:~$ tail -1 /usr/local/share/zoneinfo-posix/Australia/Sydney
    EST-10EST,M10.1.0,M4.1.0/3
On *NIX systems the HW clock is assumed to run on UTC. Therefore the difference between local time and UTC is part of a "proper" TZ variable setting ( '-10' hours in the case of the "reference" definition, but missing from your boot code).

(3) I'd imagine if you would do: TZ=UTC date (to let your system "calculate" the current time in UTC) you get a wrong result. My guess is that in your case the local time and UTC appear to be the same, which is wrong.

(4) I wonder what output you get when you check your  "HW time" and compare it with your local time. Just do: hwclock ; date

(5) There is a boot code of 'noutc' which I believe should be used in conjunction with the correct 'tz=' boot code for systems where the HW clock is not in UTC. According to my observation that boot code does not make any difference, i.e. the TC system initially boots up with the wrong time whether I specify 'noutc' or not. But if I manually enter sudo hwclock -ls (which is what 'noutc' "should be doing") my local time (as well as the "calculated" UTC time) are afterwards correct. Another way to get the correct time(s) would be to use the getTime.sh command (which fetches a correct UTC time from a time server). Obviously your TZ variable needs to provide the correct offset.

So in summary: (A) using an "incorrect" TZ variable setting does not bode well with the change over from DST to non-DST, plus (B) there might be a little flaw in the way how TC applies the 'noutc' boot code, but there are simple work-arounds to rectify the situation.

[maro]

Hmm, I believe I can suggest a minor patch that fixes the issue with the "non-working" noutc boot code:

In /etc/init.d/tc-config I simply added a export TZ statement after the line with [ -n "$TZ" ] || TZ="UTC"
My reasoning was along the lines of: How should the "poor old" 'hwclock' command know what the offset is, if no one passes on the information?

To test it I used a patched MC 2.10 initrd and QEMU. That allows to easily simulate a HW clock with UTC (which is the default) or local time. In both test cases listed here the correct times were found on the (emulated) systems:
1. HW clock on UTC:
   qemu -kernel bzImage -initrd mc_noutc.gz -append "quiet tz=NZST-12NZDT,M9.5.0,M4.1.0/3"
2. HW clock on local time:
   qemu -kernel bzImage -initrd mc_noutc.gz -append "quiet tz=NZST-12NZDT,M9.5.0,M4.1.0/3 noutc" -localtime

[roberts]

Accepted. Thanks.

[jur]

Well after working all that out, you appear to be correct.

However, what still eludes me is a workaround until the patch comes through in the next release. doing #hwclock -ls in either bootlocal or .xsession does not seem to have the desired result. I have to do it manually afterwards. Is there somewhere else I can do the TZ export?

[maro]

I believe if you add
    . /etc/sysconfig/timezone
    export TZ
    hwclock -ls
to '/opt/bootlocal.sh' you should have a workaround until the "proper fix" comes through.

Of course you can always re-master the initrd yourself (and then then possibly the ISO image, if you boot from CD-ROM).

[jur]

With tc2.11rc1, the noutc boot code is working. But daylight savings time still eludes me.

Code: [Select]

tc@box:~$ showbootcodes
quiet max_loop=255 tz=EST-10EST,M10.1.0/2,M4.1.0/2 noutc
and

Code: [Select]

tc@box:~$ showbootcodes
quiet max_loop=255 tz=EST-10EST,M10.1.0/2,M5.1.0/2 noutc
give identical results. The second case, giving the instruction to change to winter time in month 5, still results in displayed time same as hwclock.

What is the code supposed to do during summer - add one hour to the hwclock value and display that?

[maro]

@jur: At first I was also surprised about what you wrote, but I believe I've now got an explanation:

In your test the situation gets a bit muddled by the fact that the name for the standard time is in your case the same as Daylight Saving Time (i.e. EST-10EST). In my attempt to repeat your tests I took the liberty to use a different name for DST:

Code: [Select]

tc@box:~$ showbootcodes ; date
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M4.1.0/2 noutc text
Thu Apr 22 11:16:27 EST 2010
and

Code: [Select]

tc@box:~$ showbootcodes ; date
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M5.1.0/2 noutc text
Thu Apr 22 11:16:42 DST 2010
So at least this shows that the detection whether the current time is inside or outside of DST is working as expected.

Why are the times showing no difference (in local time)? Well, I guess it's due to boot code 'noutc' which "instructs" TC to use 'hwclock' for the local time. It then "calculates" out of this UTC time:

Code: [Select]

tc@box:~$ showbootcodes ; TZ=UTC date
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M4.1.0/2 noutc text
Thu Apr 22 01:33:57 UTC 2010
and

Code: [Select]

tc@box:~$ showbootcodes ; TZ=UTC date
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M5.1.0/2 noutc text
Thu Apr 22 00:34:17 UTC 2010
And there you'll now find a difference, and the latter one is "wrong". Please note that both times are incorrect as in my testing I did not fudge my own 'hwclock' and my local time zone is not EST. Nevertheless I strongly believe that this does not change the point I'm trying to make.

Another way to show the difference is to fetch the proper UTC time:

Code: [Select]

tc@box:~$ showbootcodes ; getTime.sh
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M4.1.0/2 noutc text
Wed Apr 21 23:45:05 UTC 2010
Thu Apr 22 09:45:05 EST 2010
and

Code: [Select]

tc@box:~$ showbootcodes ; getTime.sh
quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M5.1.0/2 noutc text
Wed Apr 21 23:45:14 UTC 2010
Thu Apr 22 10:45:14 DST 2010
Now we "see" the 1 hour time difference you were after, and I believe that proves that the fix has worked as expected.

Finally in an attempt to answer your question re. "summer time" I'd like to quote from the manual: "... if the offset is omitted, it defaults to one hour ahead of standard time ..."

[curaga]

Unix systems only do automatic DST when using UTC time in the bios clock. Otherwise it is presumed the bios clock is always in the proper time (ie. set by the user or a different system, like windows).

[jur]

So am I correct in concluding from this, that with noutc, the TZ boot code is irrelevant, as the computer clock isn't adjusted by the OS when DST rolls by? That is, it will know when is DST but won't do anything to the clock.

Perhaps I have to cut this last apron string tying me to Windows and go UTC. 

[curaga]

Yeah, that's right.

[maro]

I'm not quite sure that

Unix systems only do automatic DST when using UTC time in the bios clock

is a correct statement.

Here is what I did to provide some insight by jumping ahead in time to the next start of DST in Eastern Australia (using a bit of color coding to make the output a bit easier to interpret):
    tc@box:~$ showbootcodes ; date ; hwclock ; sudo date "2010-10-03 01:59:55" ; date ; sleep 10 ; date ; hwclock
    quiet max_loop=255 tz=EST-10DST,M10.1.0/2,M4.1.0/2 noutc text
    Fri Apr 23 10:07:28 EST 2010
    Fri Apr 23 10:07:29 2010  0.000000 seconds
    Sun Oct  3 01:59:55 EST 2010
    Sun Oct  3 01:59:55 EST 2010
    Sun Oct  3 03:00:05 DST 2010
    Fri Apr 23 10:07:39 2010  0.000000 seconds
I believe this shows that the changeover to DST works as expected, even when the system time is not running on UTC (and therefore the 'noutc' bootcode was used).

I certainly agree that the whole issue might be less confusing, if the BIOS clock is on UTC. Otherwise there is the "risk" that the user changes the system time twice a year.

For me the simple "solution" is to use bootcode 'tz' with or without 'noutc' (depending on the timezone of the system clock). But to be on the "save side" use an external source (e.g. 'getTime.sh') to confirm the "correct" time.

[jur]

@maro: Thanks muchly for looking into this and the detailed answers. 

After studying all, it is not entirely clear to me how to guarantee correct system time at every boot. It seems best to use getTime somewhere but if this happens after TZ is used, then...   

(more study of your answer is needed...)

[curaga]

That's what I've read around, and my previous experiences seemed to support it. But yeah, this seems to be the full case:

http://tldp.org/HOWTO/Clock-2.html

Some other documents have stated that setting the RTC to UTC allows Linux to take care of DST properly. This is not really wrong, but it doesn't tell the whole story-- as long as you don't reboot, it does not matter which time is in the RTC (or even if the RTC's battery dies). Linux will maintain the correct time either way, until the next reboot. In theory, if you only reboot once a year (which is not unreasonable for Linux), DST could come and go and you'd never notice that the RTC had been wrong for several months, because the system clock would have stayed correct all along. But since you can't predict when you'll want to reboot, it's better to have the RTC set to UTC if you're not running another OS that requires local time.