jon4t2 wrote:I had the same problem with Slacko 5.5 and the /America/New_York time zone. The fix was the same as for duck, replacing the /America/New_York file on the HD with the original from the CD. . . .
As to the origin of my problem, I ran "Updates Manager -latest from Slackware" on the Setup menu and updated tzdata.
Hi jon4t2,
Thanks for the clue. I looked into this today.
It turns out that the data files in the package are OK. But the installation script has bad manners. After the data files are installed, the script corrupts one of them. Just one. But of the hundreds of files in the package it is, of course, just the one you need.
What?! Just the America/New_York file? Gee, of all the darn luck!
Well, no, it's not always that specific file. It corrupts whatever file anyone needs, no matter what time zone they live in. For you it corrupted the America/New_York file; for duck@japan it corrupted the Asia/Tokyo file. It corrupts whichever file /etc/localtime links to.
You already know how to fix it after it is broken. Now I'll try to explain how to prevent it from happening in the first place.
Before running Updates Manager, execute the following two commands:
Code: Select all
mv /etc/localtime /etc/localtime-copied-from
cp -p /etc/localtime-copied-from /etc/localtime
Then run the Updates Manager and install glibc-zoneinfo.
After running Updates Manager, execute the following command:
Code: Select all
mv /etc/localtime-copied-from /etc/localtime
That should do it.
Now, if you want any of the boring details of what the problem was, read on.
Puppy, like most distros I am familiar with, indicates the local time zone with a symbolic link at /etc/localtime which points to the appropriate data file in a subdirectory of /usr/share/zoneinfo. Alternatively, the same result can be achieved by actually copying the appropriate data file to /etc/localtime. I don't know which distros use the latter method, but judging by the installation script for this package, I am guessing that Slackware is one distro that does.
Not only is /etc/localtime a copy of the data file for the desired time zone, but there is also a symlink named /etc/localtime-copied-from, which points to the data file that was copied. The purpose of that file is to allow the installation script for the zoneinfo package to copy the new version of the desired file to /etc/localtime again, after the new data files are installed.
That may work fine on a Slackware installation, but Puppy doesn't usually have a file at /etc/localtime, just a symlink. Nor does Puppy set the /etc/localtime-copied-from symlink.
In Slacko, that symlink normally just stays at its original value, which points to /usr/share/zoneinfo/Factory (as in "factory settings"). That file contains no actual zone information, but sets the string normally used for the zone name (such as "GMT" or "BST") with the message "Local time zone must be set--see zic manual page", which is sometimes (depending upon your language settings) displayed when the date command is executed, like so:
Code: Select all
# date
Sun Jun 23 02:25:52 Local time zone must be set--see zic manual page 2013
#
So, when the installation script copies the file pointed to by /etc/localtime-copied-from to /etc/localtime, you may start seeing that message, and Psync will no longer work right.
Worse, remember that /etc/localtime is a symlink on Puppy, so the Factory file doesn't get copied there; it actually follows the link to whatever file /etc/localtime points to, in your case /usr/share/zoneinfo/America/New_York, overwriting that file. So now the file with the updated data you wanted has been destroyed.
Not good.
The sad thing is that it looks like the installation script was originally designed to handle the situation when it encountered a symlink instead of a file at /etc/localtime. If there is no /etc/localtime-copied-from symlink, the script will create it by renaming /etc/localtime to /etc/localtime-copied-from. Thus, it would be able to later copy the correct file to /etc/localtime instead of the Factory file.
So far, that's good. But the very next thing it does when it can't find a readable /etc/localtime (which it can't, since it just renamed it) is to blow away both /etc/localtime (which is already gone) and /etc/localtime-copied-from. Silly. Possibly the result of an untested patch to the script.
But even if the script did work properly, there could still be problems, since once /etc/localtime-copied-from was created, and the desired data file was copied to /etc/local time, if the user ran quickcountry, /etc/localtime-copied-from wouldn't be updated, and /etc/localtime would revert to a symlink.
jon4t2 wrote:. . . perhaps a Puppy specific tzdata set is needed.
That might be the best solution. Also it would be good if this package was filtered out of the list of packages found at the Slackware updates repository, so that users would not be temped to try and install it.
Anyway, thanks for reporting your experience with this, and especially what you did that caused it. It was the key to solving this mystery.
but it should work.
I just assumed you knew how to use ROX.