Changing timezone in ‘localization’ applet changes time too, it
should not. The applet should adjust time so when calculated with new TZ
it will bring the same time as before.
There is no interface to change time in the plugin, should be.
New time does not get written to hardware, it should.
Even if you change timezone and do ‘rtc -s hw’ manually, after reboot
OS time will be the same as hardware (even if that is UTC), until you
do ‘rtc hw’ manually.
But that is just tip of the iceberg. More fundamantal problem is, there
appears to be time calculation inconsistencies. Watch this:
date (after boot)
XXX XXX XX 22:05:XX cdt 2000 (same as hardware)
2. # cat /etc/TIMEZONE (set to Central by ‘localization’ applet).
cst06cdt05,M4.1.0/2,M10.5.0/2
3. rtc hw
4. # date
XXX XXX XX 16:05:XX cdt 2000
Note, date reports ‘cdt’ (offset is 5 hours) but offset between reported
date and UTC is 22-16=6 hours.
It also reports ‘cdt’ before ‘rtc hw’ command is issued when offset is
in fact 0.
I tried to set time 1 hour ahead, rebooted, did ‘rtc hw’ and got proper
local time. Tried it on two completely different machines, same way.
Looks like bug to me.
Changing timezone in ‘localization’ applet changes time too, it
should not. The applet should adjust time so when calculated with new TZ
it will bring the same time as before.
There is no interface to change time in the plugin, should be.
New time does not get written to hardware, it should.
Even if you change timezone and do ‘rtc -s hw’ manually, after reboot
OS time will be the same as hardware (even if that is UTC), until you
do ‘rtc hw’ manually.
But that is just tip of the iceberg. More fundamantal problem is, there
appears to be time calculation inconsistencies. Watch this:
date (after boot)
XXX XXX XX 22:05:XX cdt 2000 (same as hardware)
2. # cat /etc/TIMEZONE (set to Central by ‘localization’ applet).
cst06cdt05,M4.1.0/2,M10.5.0/2
3. rtc hw
4. # date
XXX XXX XX 16:05:XX cdt 2000
Note, date reports ‘cdt’ (offset is 5 hours) but offset between reported
date and UTC is 22-16=6 hours.
It also reports ‘cdt’ before ‘rtc hw’ command is issued when offset is
in fact 0.
I tried to set time 1 hour ahead, rebooted, did ‘rtc hw’ and got proper
local time. Tried it on two completely different machines, same way.
Looks like bug to me.
Changing timezone in ‘localization’ applet changes time too, it
should not. The applet should adjust time so when calculated with new TZ
it will bring the same time as before.
There is no interface to change time in the plugin, should be.
New time does not get written to hardware, it should.
Even if you change timezone and do ‘rtc -s hw’ manually, after reboot
OS time will be the same as hardware (even if that is UTC), until you
do ‘rtc hw’ manually.
But that is just tip of the iceberg. More fundamantal problem is, there
appears to be time calculation inconsistencies. Watch this:
date (after boot)
XXX XXX XX 22:05:XX cdt 2000 (same as hardware)
2. # cat /etc/TIMEZONE (set to Central by ‘localization’ applet).
cst06cdt05,M4.1.0/2,M10.5.0/2
3. rtc hw
4. # date
XXX XXX XX 16:05:XX cdt 2000
Note, date reports ‘cdt’ (offset is 5 hours) but offset between reported
date and UTC is 22-16=6 hours.
It also reports ‘cdt’ before ‘rtc hw’ command is issued when offset is
in fact 0.
I tried to set time 1 hour ahead, rebooted, did ‘rtc hw’ and got proper
local time. Tried it on two completely different machines, same way.
Looks like bug to me.
No answer from QNX, huh? Should we take it as nobody cares or as nobody
gives a damn?
Actually, it was that the fellow who is looking at this stuff (Russian import)
didn’t know how to use tin or the newsgroups… he’s catching up on his
reading now.
