After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 581508 - /usr/share/zoneinfo/ isn't being parsed correctly
/usr/share/zoneinfo/ isn't being parsed correctly
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: clock
2.26.x
Other All
: Normal normal
: ---
Assigned To: Milan Crha
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-05 18:49 UTC by David Ronis
Modified: 2009-10-15 17:09 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
proposed eds patch (1.02 KB, patch)
2009-05-07 12:32 UTC, Milan Crha
none Details | Review
libical extension (1.02 KB, text/plain)
2009-05-19 15:08 UTC, Milan Crha
  Details
proposed eds patch ][ (810 bytes, patch)
2009-05-19 18:47 UTC, Milan Crha
committed Details | Review

Description David Ronis 2009-05-05 18:49:58 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:
Comment 1 Milan Crha 2009-05-05 19:14:56 UTC
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?
Comment 2 Milan Crha 2009-05-07 12:32:09 UTC
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.
Comment 3 Milan Crha 2009-05-07 12:33:52 UTC
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.
Comment 4 Milan Crha 2009-05-19 15:08:50 UTC
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.)
Comment 5 David Ronis 2009-05-19 16:12:10 UTC
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.)

Comment 6 Milan Crha 2009-05-19 18:47:43 UTC
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.
Comment 7 Art Cancro 2009-05-31 15:38:25 UTC
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?
Comment 8 Milan Crha 2009-10-15 17:09:26 UTC
(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+)