GNOME Bugzilla – Bug 581508
/usr/share/zoneinfo/ isn't being parsed correctly
Last modified: 2009-10-15 17:09:37 UTC
Please describe the problem: I've set my /etc/localtime to "Canada/Eastern" but when I try to do this for the clock applet, the best it does is "America/Montreal" which is OK for most things. This seems to be a more low-level bug that is causing problems in evolution's calendar. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
We had investigated this within gnome-panel clock applet and evolution itself (as they have the same code for detecting a system timezone location). David's system is Slackware, and as we found all methods to get timezone information fails except of the last two, >(gdb) p system_timezone_read_etc_localtime_hardlink() > $8 = "localtime" >(gdb) p system_timezone_read_etc_localtime_content() > $9 = 0x8447b90 "Canada/Eastern" David found that glibc-zoneinfo-2.9-noarch-3.tgz's doinst.sh file contains > # Add the default link in /usr/share/zoneinfo, if none exists: > ( cd usr/share/zoneinfo ; ln -sf /etc/localtime localtime ) which as discussed with vuntz is considered as The Bad Thing. We'll try to ask them for some better explanation or even better for a removal (I'm not sure whether they maintain the package at all, but will see). I will attach a patch with checking for non-symlinks in the first system_timezone_read... function, and as discussed with vuntz, in the second skipping "localtime" file names, to keep possible symlinking on other distributions. But we do not stop here. When you try to choose the timezone in the clock-applet, or evolution, then you can see there is no Canada node, thus even the underlying function returns correct location "Canada/Eastern", then it is not found and evolution still shows UTC (it's a fallback). Note that even mine /usr/share/zoneinfo contains Canada/Eastern file. I just found that the /usr/share/zoneinfo/zone.tab doesn't contain any Canada references, which might explain why this doesn't work. Any idea where to ask? Where does clock applet get his location list I do not know, also libical or its own list somewhere?
Created attachment 134190 [details] [review] proposed eds patch for evolution-data-server; This is a patch done in a way as discussed with vuntz. The same change, even in a different file and folder (function names are same), might come to the clock applet, if approved.
Forgot to mention, it doesn't fix all the bug, only the part of misfound 'localtime' as a timezone location. The issue with not mentioned Canada/... subfolder in the zone.tab file is probably a question on someone completely else.
Created attachment 134942 [details] libical extension I had a chat with a co-worker, and he told me that obsolete timezones are not mentioned in the zone.tab file. The timezone can be made obsolete by typo in its name or by change in a timezone naming convention, (and many other ways too). The later happened here probably, as "Canada/*" had been "renamed" to "America/*" for some naming convention reason. (I hope I do not mix things much here). Nonetheless, the obsolete timezone definition files are still there, for the backward compatibility. I was told to fix this in libical, where comes this little patch. I'll try to post it to libical upstream, and let's see. (This is otherwise unrelated to this bug, aka doesn't block it, from my point of view.)
I applied the patch. It changes the behavior in evo's calendar preferences in that edit->preferences->calendar->general now shows "(localtime)" instead of "(UTC)" and selecting "Use system time zone" doesn't corrupt the calendar. Trying to select a timezone manually still doesn't show the old Canada/Montreal entry (although I'm not sure that it should). Related to this is in gnome's clock applet (2.26.1); it still shows America/Toronto, even though it is using the data for montreal (longitude and lattitude, etc.)
Created attachment 134965 [details] [review] proposed eds patch ][ for evolution-data-server; As we found with Dave, the previous eds patch just doesn't work, because of a stupid mistake I did (there was compared "/localtime" against "localtime"), and that the S_ISLNK doesn't work there, because it's returned from the g_stat call, which calls stat, which follows symlinks, (thus the inode is same for them), whereas g_file_test uses lstat. Nonetheless, just workarounding this issue on slackware, thus checking the file name. We also found out that the first chunk, for file content compare, wasn't necessary, thus it's removed from the patch.
We are prepared to apply the patch supplied in comment #4 to libical upstream, if you have determined that it is effective. Have you determined its effectiveness yet?
(In reply to comment #7) > We are prepared to apply the patch supplied in comment #4 to libical upstream, > if you have determined that it is effective. Have you determined its > effectiveness yet? Hi Art, I'm so sorry for the late response, I overlook your question for a reason I do not know. I'm really sorry for that. Strange to ask you, but anyway: what kind of effectiveness do you mean? Like whether it works or whether it's usable on any other system than Slackware? I believe it's good to have in libical, for the backward compatibility. I committed the eds workaround, but we can discuss the libical part here more, if you want to. Created commit 5858bc3 in eds master (2.29.1+)