From kde-commits Sat Jul 09 02:43:20 2005 From: Shaheed Date: Sat, 09 Jul 2005 02:43:20 +0000 To: kde-commits Subject: Re: KDE/kdelibs/kdecore/tests Message-Id: <200507090442.22089.srhaque () iee ! org> X-MARC-Message: https://marc.info/?l=kde-commits&m=112087700014454 David, Thanks for the test. The bulk of the "problems" are expected: they are the consequence of trying to support all the logic that the original code I scoured had, but eliminating the platform #ifdef's where I could. As near as I can tell from reading the code, looking at the Solaris systems I have access to (but where I cannot build KDE), and Googling for platform man files etc. I have incorporated the code for BSD and Solaris support...hence all the missing files on your system. More detail below. > More info: > > ktimezonestest: Can't open /etc/timezone > > No such file at all. AFAICS, this file is a BSD file. Note that such a file is *created* unconditionally by kcontrol/clock/tzone.cpp (its obviosuly ignored on Linux, hence my comment about this in my checkin 432367 of this file!), and the code for reading it came from there. Thus, this kdDebug() message is expected. > > grep: /etc/default/init: Permission denied > > /etc/default only has "useradd" anyway, no "init" in it. > > > zsh: no such file or directory: /bin/head > > It's in /usr/bin. Ditto, but for Solaris. Again, the code comes from kcontrol/clock/tzone.cpp. If I could think of a shell-independent way of redirecting the output, I would add it, but I cannot :-). > But C++ code should probably read the file itself instead > of relying on shell tools. > > > ktimezonestest: Can't open /tmp/kde-dfaure/ktimezonestestXdj0Fa.tmp > > The code is grepping a just-created KTempFile? What for? Yeah, I know. The original code use the shell stuff and popen()...all I did was eliminate the popen(). > > Local timezone: Africa/Algiers > > date shows "CEST" btw, which is correct, given that I live in France ;) > > (the result of this bug is that the clock applet is one hour off in "local > timezone") See below. > Quick look at the code: > - new KShellProcess() < never deleted. Thanks, fixed. > - if (!f.open(IO_ReadOnly)) < called twice in a row It's OK, note the "!". It is actually called three times in a row elsewhere :-). > - $TZ < not set here (Mandriva 10.2) > > Strace on "date" says > open("/etc/localtime", O_RDONLY) = 3 > > file /etc/localtime > /etc/localtime: timezone data Right. This is the last missing piece of logic (see the FIXME in the code). Once this is addressed this weekend, the idea is that only if all the definitive sources of data on BSD, Solaris and Linux have been exhausted, then the heuristic will cut in. Since this logic is not there, the code tried to match CEST against the zoneinfo database and matched "Africa/Algiers": that's probably a bug (I suspect I somehow matched CET/CEST against CET/WEST). I will look for this bug, and also plan to improve the heurisitc to take into account the minimum time delta between the candidate timezones and your system's localtime. With those two, I would hope the logic of local() would be robust enough to make this algorithm almost perfect. Watch this space. Thanks, Shaheed P.S. I really appreciate the feedback: this is a tricky area to get right. And any more pointers on the implementation given the points above are appreciated. Maybe once we get it right, Qt will pick it up!