Timezone can't be set - SOLVED, kinda

[erikson]

Post deleted because somewhat misleading and incomplete. See my next post.

[Béèm]

This document

In other words, POSIX counts time offsets negative for zones east of the Greenwich meridian, where time is ahead of GMT. (Source of quote: http://www.twinsun.com/tz/tz-link.htm)

I did the right thing to set the TZ at Europe/Brussels

[erikson]

I did the right thing to set the TZ at Europe/Brussels

I checked now for Puppy 4.00-k2.6.21.7-seamonkey

Apparently the timezone GUI has a range of new "continent/city" entries, including the Europe/Brussels entry as you mention. I tested this one, and indeed it does give the right offsets!

But the timezone GUI still has the older "GMT+-n" entries from previous versions, and these older entries are still just as wrong as they were in previous Puppies. GUI selection of a "GMT+-n" timezone creates a symlink /etc/localtime to /usr/share/zoneinfo/Etc/GMT-+n (i.e. with inverted sign). For instance, the old timezone selection "GMT+1 (Paris, Berlin, Amsterdam, Brussels...)" actually gives localtime one hour behind GMT, whereas the old timezone selection "GMT-2 (Mid-Atlantic)" gives the correct time for CEST, two hours ahead of GMT.

My conclusion: in Puppy 4 series, you can safely use the timezone GUI with the new-style "continent/city" entries, but you should avoid the old-style "GMT+-n" entries (or use them with inverse sign, as for Puppy series 2 and 3).

[John Doe]

But the timezone GUI still has the older "GMT+-n" entries from previous versions, and these older entries are still just as wrong as they were in previous Puppies. GUI selection of a "GMT+-n" timezone creates a symlink /etc/localtime to /usr/share/zoneinfo/Etc/GMT-+n (i.e. with inverted sign). For instance, the old timezone selection "GMT+1 (Paris, Berlin, Amsterdam, Brussels...)" actually gives localtime one hour behind GMT, whereas the old timezone selection "GMT-2 (Mid-Atlantic)" gives the correct time for CEST, two hours ahead of GMT.

You might have found a bug there.

My conclusion: in Puppy 4 series, you can safely use the timezone GUI with the new-style "continent/city" entries, but you should avoid the old-style "GMT+-n" entries (or use them with inverse sign, as for Puppy series 2 and 3).

4 series works fine for GMT-5 here. I use the 'old-style "GMT+-n" entries' as well as dual boot XP. Clock is always correct.

[Béèm]

Is your machine dual-boot? I just wonder if your Windows time is correct.

Yes I dual boot to windows and the time stays correct.
But you are right, the problems I was talking about was when I tried via gmt + or -.
Now with the region/city selection no problems anymore.

In fact I had the problem in 3.02 and MU had sent me the Dingo 4 TZ directory. The one of 3.02 was empty.

[erikson]

So it appears that we all found some way to get time set as we want it, even though our findings are not completely compatible.

Anyway, with respect to timezone configuration, Puppy 4 certainly is a big step forward.

Thanks to all for sharing your experiences.

[Béèm]

Yes Dingo seems to be a good platform.

[BarryK]

But the timezone GUI still has the older "GMT+-n" entries from previous versions, and these older entries are still just as wrong as they were in previous Puppies. GUI selection of a "GMT+-n" timezone creates a symlink /etc/localtime to /usr/share/zoneinfo/Etc/GMT-+n (i.e. with inverted sign). For instance, the old timezone selection "GMT+1 (Paris, Berlin, Amsterdam, Brussels...)" actually gives localtime one hour behind GMT, whereas the old timezone selection "GMT-2 (Mid-Atlantic)" gives the correct time for CEST, two hours ahead of GMT

No, there's nothing wrong with the timezone GUI in all recent puppies 2 -4. This was worked out ages ago. The sign inversion is correct. Here in Perth Australia my timezone is GMT+8, however the people who designed the GMT timezone files decided in their wizdom to invert the signs. So, I have /etc/localtime linked to /usr/share/timezone/Etc/GMT-8, which is correct. Note, Puppy assumes your hardware clock is set to local time, which is usually what Windows expects also.

[erikson]

I stand corrected.

So I have some homework to do, until I precisely understand how time works in Puppy and why I got it wrong, even though time display systematically looked okay on my laptop (???).

I had noticed months ago that GUI setting GMT+n makes a localtime symlink to timezone file GMT-n and also results into hwclock displaying timezone indicator GMT-n --- which, I presume, reflects the notorious POSIX timezone sign inversion that has confused so many of us, and which may have led me to assume that the GUI was backwards.

[erikson]

Following console snapshot removes all doubt.

I'm running pcPuppyOS (3.01 derivative). I first used the GUI to set timezone to GMT+2 (my localtime is CEST, two hours ahead of GMT).

Code: Select all

1# ls -l /etc/localtime
lrwxrwxrwx 1 root root 25 2008-09-03 18:35 /etc/localtime -> /usr/share/zoneinfo/GMT-2
1# 
1# hwclock
Wed 03 Sep 2008 06:39:20 PM GMT-2  -0.376946 seconds
1# 
1# date
Wed Sep  3 18:39:27 GMT-2 2008
1# 
1# date -u
Wed Sep  3 16:39:35 UTC 2008
1#

The ls command shows that localtime is symlinked to timezone file GMT-2 (inverted sign). The hwclock command displays RTC time, set to localtime, with timezone GMT-2 (inverted sign). The first date command displays localtime with timezone GMT-2 (inverted sign). The second date command with option -u shows UTC time.

Both date commands (localtime resp. UTC) ought to correspond, and indeed 18:39 CEST localtime is 16:39 UTC. This is the ultimate evidence that hwclock and date timezones must be interpreted in POSIX sign-inverted sense (negative sign for timezones ahead of GMT), while the GUI GMT-with-offset timezones must be interpreted in the normal way (positive sign for timezones ahead of GMT).

---

From my notes I also have found the reason why I had selected the "inverse" timezone, several months ago. I think that I have a reasonable excuse

With my new timezone setting, compliant with Barry's indications, I rebooted Puppy around 18:55 CEST = 16:55 GMT. See below snapshot of /tmp and look at the timestamps.

Some files have a CEST timestamp, and a few other files have a timestamp 2 hours ahead of CEST. The latter are files created early in the boot process, before the switch-root at the end of the init script of initrd.gz.

With my earlier (inverted) timezone setting, those "early" files have a timestamp 2 hours behind localtime --- i.e. in UTC!!! Since I tend to prefer a few timestamps in UTC rather than timestamps in the future, this is the reason that led me to choose the "wrong" sign.

I can only guess about the origin of those bizarre timestamps. Note that I have taken care to keep my RTC always in localtime, as that's also what Windows expects. The only explanation I can think of is that, somehow, timezone offset is kept in the RTC of my laptop (*), but with a sign that is interpreted incorrectly by the kernel during the early phases of the boot process (later on, the kernel uses its own systemtime and doesn't look at the RTC anymore).

Conclusion: I'll stick with Barry's suggestion (since that gives correct UTC time and localtime readings for the date command), and I won't worry about a couple of in-the-future timestamps for files in /tmp.

(*) As I found on the web, some RTC chips keep timezone offset while other ones don't. That's why I referred earlier to "my" findings on "my" laptop.

[Bruce B]

I've not complaints, but if I wrote /etc/profile, I'd have to take it up with it's author.

Before erikson stands corrected any more, and my not wanting to
see him to have to sit corrected, I'll explain the best way I know to
make a person wonder which way the earth spins. Install a time sync utility in Puppy and see if it syncs or throws things out of whack.

[erikson]

if I wrote /etc/profile, I'd have to take it up with it's author.

You may have wondered about eeelog and tlog in the directory listing that I posted; eeelog is an experimental relic that I forgot to clean up; for tlog see...

Code: Select all

1# cat /tmp/tlog
2008-09-04 16:21:05.405 (1,,1714) /etc/rc.d/rc.sysinit
2008-09-04 16:21:05.738 (2,,1838) /etc/rc.d/rc.update
2008-09-04 16:21:05.788 (1,,1714) /etc/rc.d/rc.modules
2008-09-04 16:21:08.251 (2,,2567) /etc/rc.d/rc.alsa
2008-09-04 16:21:08.678 (1,,1714) /etc/rc.d/rc.local0
2008-09-04 16:21:08.734 (1,,1714) /etc/rc.d/rc.modules2
2008-09-04 16:21:08.872 (2,,2857) /etc/rc.d/rc.country
2008-09-04 14:21:10.010 (2,,2872) /etc/rc.d/rc.network
2008-09-04 14:21:10.025 (2,,2890) /etc/rc.d/rc.modem
2008-09-04 14:21:11.441 (2,,3050) /etc/rc.d/rc.modem
2008-09-04 14:21:11.492 (1,,1714) /etc/rc.d/rc.local
2008-09-04 14:21:12.474 (1,,3276) /etc/profile
2008-09-04 14:21:12.599 (1,,3276) /etc/profile.d/qt.sh
2008-09-04 14:21:12.602 (1,,3276) added for test... /etc/profile.d/test.sh
2008-09-04 14:21:12.618 (1,,3276) /usr/X11R7/bin/xwin
2008-09-04 14:21:15.321 (2,,3409) /root/.xinitrc
2008-09-04 14:21:23.590 (3,1,3575) /root/.bashrc
1#

You're right, I fiddled a wee bit with /etc/profile and other scripts (i.e. added logging to tlog).

I booted around 14:21 local time (CEST) = 2 hours ahead of GMT. From above log, it's obvious in which script I have to look for the transition from anomalous timestamps, 2 hours ahead of localtime = 4 hours ahead of GMT (!!!), to correctly reported localtime.

Before erikson stands corrected any more, and my not wanting to see him to have to sit corrected...

Don't worry, I have no Linux reputation to defend

... I'll explain the best way I know to make a person wonder which way the earth spins.

... but as an amateur astronomer, I happen to know already which way the earth spins.

Install a time sync utility in Puppy and see if it syncs or throws things out of whack.

Actually pcPuppyOS has a time sync utility built in, and I tried it months ago. I never succeeded in letting it sync, however, and it didn't throw anything out of whack either, it just reported failure to sync. That was the case with my earlier timezone setting, and it still is the case with my corrected setting.

Under Windows, timesyncing with the same NTP servers (such as ntp1.oma.be and ntp2.oma.be in Belgium) succeeds three times out of four.

--- Edit @ 15:27 CEST

Here's how /etc/rc.d/rc.country ends...

Code: Select all

#need to set Linux system time/date, from hardware clock...
hwclock --hctosys --localtime
#...--hctosys reads cmos clock to system.
#...--localtime means that cmos clock is set to local-time.

So that's where Puppy reloads system time from the hardware clock. Before that, there's another system time active, also derived from the RTC and from the timezone setting (obviously)... but with the opposite sign assumption.

In other words, Puppy chooses to disagree with system time as set up originally at bootup by the kernel. I can imagine there may be good reasons for doing so (e.g. the fact that Windows insists on having RTC in localtime, not in UTC). Whatever... it may have confused me for a few months, but it won't change the earth's spin direction, though.

I bet it should be possible to correct even this timestamp anomaly (for anything timestamped before rc.country executes) by suitably patching and recompiling the kernel, but as yet that's a wee bit above my skills.

[erikson]

Time for final wrap-up

I now also added timelogging in the init script of initrd.gz

Note that this is somewhat involved:
(1) unpack initrd.gz
(2) add date and its dependencies (are not included in the regular initrd.gz)
(3) edit init script: add a tlog() function, plus calls to this function at every output to console
(4) repackage initrd.gz

Output (I rebooted at 16:41 CEST = 14:41 GMT):

Code: Select all

# cat /tmp/tlog
2008-09-09 16:41:33.748 (,,1) init: Loading kernel drivers needed to access disk drives
2008-09-09 16:41:40.896 (,,1) init: Searching for Puppy files in computer disk drives
2008-09-09 16:41:41.179 (,,1) init: Loading personal storage file /puppOSfin/pup_save-pOSfin.2fs (sda1)
2008-09-09 16:41:43.203 (,,1) init: Loading the 'pup_301.sfs' main file
2008-09-09 16:41:43.882 (,,1) init: Setting up the Unionfs layered filesystem
2008-09-09 16:41:43.964 (,,1) init: Preparing switch_root to the new Unionfs filesystem
2008-09-09 16:41:45.447 (,,1) init: Copying tlog to the new /tmp folder
2008-09-09 16:41:45.458 (,,1) init: Now executing the switch_root
2008-09-09 18:41:45.742 (1,,2282) /etc/rc.d/rc.sysinit
2008-09-09 18:41:46.066 (2,,2406) /etc/rc.d/rc.update
2008-09-09 18:41:51.228 (1,,2282) /etc/rc.d/rc.modules
2008-09-09 18:41:53.700 (2,,11968) /etc/rc.d/rc.alsa
2008-09-09 18:41:54.121 (1,,2282) /etc/rc.d/rc.local0
2008-09-09 18:41:54.175 (1,,2282) /etc/rc.d/rc.modules2
2008-09-09 18:41:54.320 (2,,12258) /etc/rc.d/rc.country
2008-09-09 16:41:55.011 (2,,12273) /etc/rc.d/rc.network
2008-09-09 16:41:55.019 (2,,12280) /etc/rc.d/rc.modem
2008-09-09 16:41:56.450 (2,,12456) /etc/rc.d/rc.modem
2008-09-09 16:41:56.501 (1,,2282) /etc/rc.d/rc.local
2008-09-09 16:41:57.745 (1,,12682) /etc/profile
2008-09-09 16:41:57.853 (1,,12682) /etc/profile.d/qt.sh
2008-09-09 16:41:57.855 (1,,12682) added for test... /etc/profile.d/test.sh
2008-09-09 16:41:57.871 (1,,12682) /usr/X11R7/bin/xwin
2008-09-09 16:42:00.610 (2,,12815) /root/.xinitrc
2008-09-09 16:42:16.607 (3,1,13001) /root/.bashrc
#

The timestamps are okay throughout the init script, i.e. the systemtime set by the kernel at startup corresponds to the correct localtime. Obviously the kernel reads the RTC and uses this reading as systemtime, without applying any timezone correction (both pup_save and pup_xxx have not yet been loaded, and thus there is no /etc/localtime).

Just after the switch_root, the timestamps are changed --- now localtime + 2 hours. This means that systemtime has been reset by the invoked function (i.e. /sbin/init = symlink to the init function in busybox). At this moment, /etc/localtime is available and reflects the user-configured timezone. Apparently the busybox init function reads the RTC, assumes that the RTC running in utc, calculates localtime by correcting for the specified timezone assuming POSIX convention, and sets systemtime to this calculated localtime. Because of the mentioned assumptions, in my case (CEST) it's now 2 hours wrong, in the opposite direction of GMT !!!

Then, as mentioned before, systemtime is reset in /etc/rc.d/rc.country from the RTC, under the (correct) assumption that it's running in localtime. No timezone correction is applied (nor needed) since it already is localtime.

Now it won't be difficult anymore to get rid of those few timestamp anomalies. The simplest solution is to move the systemtime reset from the end of /etc/rc.d/rc.country to the very beginning of /etc/rc.d/rc.sysinit that runs immediately after busybox init (as defined in /etc/inittab).

[erikson]

Now it won't be difficult anymore to get rid of those last few timestamp anomalies between switch_root and rc.country. The simplest solution is to move the systemtime reset from the end of /etc/rc.d/rc.country to the very beginning of /etc/rc.d/rc.sysinit that runs immediately after busybox init (as defined in /etc/inittab).

In the mean time I've done so (I just forgot to report).

Hereunder my timelogs from patched Puppy. All times are consistently localtime.

Code: Select all

1# cat /tmp/elog
puppOSfin
2008-12-21 10:11:43.030 (,,1) init: Loading kernel drivers for disk access
2008-12-21 10:11:51.260 (,,1) init: Searching for Puppy files
2008-12-21 10:11:53.471 (,,1) init: Loading /puppOSfin/pup_save-pOSfin.2fs
2008-12-21 10:11:56.533 (,,1) init: Loading pup_301.sfs main file
2008-12-21 10:11:56.589 (,,1) init: Setting up the layered filesystem
2008-12-21 10:11:56.616 (,,1) init: Preparing switch_root
2008-12-21 10:11:56.712 (,,1) init: Now executing the switch_root
2008-12-21 10:11:59.030 (1,,1851) /etc/rc.d/rc.sysinit
2008-12-21 10:11:59.454 (2,,1974) /etc/rc.d/rc.update
2008-12-21 10:11:59.542 (1,,1851) /etc/rc.d/rc.modules
2008-12-21 10:12:02.215 (2,,2703) /etc/rc.d/rc.alsa
2008-12-21 10:12:02.704 (1,,1851) /etc/rc.d/rc.local0
2008-12-21 10:12:02.795 (1,,1851) /etc/rc.d/rc.modules2
2008-12-21 10:12:02.970 (2,,3011) /etc/rc.d/rc.country
2008-12-21 10:12:03.023 (2,,3025) /etc/rc.d/rc.network
2008-12-21 10:12:03.072 (2,,3047) /etc/rc.d/rc.modem
2008-12-21 10:12:04.558 (2,,3208) /etc/rc.d/rc.modem
2008-12-21 10:12:04.620 (1,,1851) /etc/rc.d/rc.local
2008-12-21 10:12:04.946 (1,,3400) /etc/profile
2008-12-21 10:12:05.219 (1,,3400) /etc/profile.d/qt.sh
2008-12-21 10:12:05.232 (1,,3400) /etc/profile.local
2008-12-21 10:12:05.273 (1,,3400) /usr/X11R7/bin/xwin (entry)
2008-12-21 10:12:08.270 (2,,3539) /root/.xinitrc
2008-12-21 10:12:13.036 (3,,3652) /usr/sbin/delayedrun
2008-12-21 10:12:29.943 (2,,3392) /mnt/home/bin/e-startup
2008-12-21 10:12:29.971 (3,,3762) /mnt/home/bin/e-meminfo
2008-12-21 10:12:30.070 (3,,3768) /mnt/home/bin/e-httpd start
2008-12-21 10:12:30.115 (3,,3775) /mnt/home/bin/e-pingd
2008-12-21 10:12:30.137 (3,,3776) /mnt/home/bin/e-myipd: probing router...
2008-12-21 10:12:37.976 (3,,3776) /mnt/home/bin/e-myipd: IP=81.242.106.244
2008-12-21 10:47:09.860 (3,,12812) /usr/sbin/snapmergepuppy
2008-12-21 10:54:43.092 (3,1,15551) /root/.bashrc
2008-12-21 11:17:10.629 (3,,21584) /usr/sbin/snapmergepuppy
2008-12-21 11:47:20.527 (3,,30336) /usr/sbin/snapmergepuppy
2008-12-21 12:17:23.440 (3,,6435) /usr/sbin/snapmergepuppy
2008-12-21 12:47:25.432 (3,,15191) /usr/sbin/snapmergepuppy
2008-12-21 13:17:27.741 (3,,23955) /usr/sbin/snapmergepuppy
2008-12-21 13:47:30.726 (3,,32705) /usr/sbin/snapmergepuppy
2008-12-21 14:17:34.454 (3,,9052) /usr/sbin/snapmergepuppy
1#

[Aitch]

erikson

You get my 3 stars - ***

Thanks for the excellent exampled explanation,
I actually followed, for the first time, what has puzzled me for over a year with this timestamp 'anomaly'

Aitch

[Colonel Panic]

Sorry, but my head's spinning here. My computer clock's running 8 hours fast in Lighthouse Pup (4.1.2) and I live in the UK so am on GMT. Is there an easy way to fix this?

Thanks in advance,

Colonel Panic.

[Béèm]

No panic.
I suppose you have menu|desktop as well
In desktop you can set timezone to UK, London f.e. and adjust the clock if needed.

[Colonel Panic]

Thanks. It does work but (and I hope this is clear) when Puppy boots back up again after the time has been reset the timezone shown in the "Puppy timezone selector" window resets to Perth time even though the time in the JWM taskbar displays the normal zone set.

[Béèm]

Maybe a problem in Lighthouse pup. When I do the setting it sticks. Try to PM the developer of Lighthouse.

[Colonel Panic]

Thanks for the suggestion.

It worked OK this time. I'm very reluctant to trouble the devs with anything which could turn out to be my fault. If it happens again I'll do as you suggest.

Regards.

Colonel Panic.