Tiny Core Base > TCB Q&A Forum

Computer time incorrect?

(1/3) > >>

jur:

--- Code: ---tc@box:~$ showbootcodes
quiet tce=sda7 opt=sda7 home=sda7 max_loop=255 tz=EST,M10.1.0/2,M4.1.0/2 noicons
--- End code ---

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?

Navigation

[0] Message Index

[#] Next page