[patch] KTimezone tests

[Shaheed]

On Thursday 29 December 2005 13:34, David Jarvie wrote:
> It looks like KSystemTimezones::local() for some reason isn't finding a
> match between your /etc/localtime and any of the files in
> /usr/share/zoneinfo. (The file should have the same contents as one of the
> zoneinfo files.) This presumably is due either to there being no matching
> file, or due to it not being listed in /usr/share/zoneinfo/zone.tab. After
> failing to find a match, the value of the TZ environment variable is used
> as a fallback. This ('EST') translates to a UTC offset of -5 hours (the
> -18000 which the test reports).

This is trunk, right? Looking at the code again, if you have a TZ setting, it 
should work like this:

	1. We find there is a TZ setting, and try to look it up in the internal list 
of timezones. That will fail since "EST" is not listed in zone.tab (which 
controls how the internal list was built).

        2. Since you have a /etc/localtime file, this will be compared against 
the internal list, and will fail again for the same reason.

	3. Various other deterministic options will be tried all of which will 
probably fail (since they are supposed to work on BSD etc.). hence the "Can't 
open xxx" messages.

	4. You'll end up at the heuristic and the end of the function. This tries to 
match the global tzname[0] and tzname[1] values returned by tzset() with the 
abbreviations in the internal list of timezones. Since these are not unique, 
it tries to find a "best" match by minimising the timeoffset.

I suspect what's going on here is that the heuristic is picking the wrong 
zone. Try printing the zone name (local->name()).

> I don't know how much testing was done on the local time zone code, but
> what you have found suggests that there may be bugs. Perhaps Shaheed can
> comment?

I did all my "real" testing on Mandriva, with some fragments getting tested on 
Solaris 8. I made the heuristic robust enough to find my zone (!!) - an 
exhaustive test was not on the cards.

Hmmm. Perhaps the real solution here is that the internal database should 
contain *all* the files recursively listed in /usr/zoneinfo, and not just the 
subset listed in zone.tab? I did consider that, but did not take that route 
since the unlisted entries definitely seem to be second class entries - bad 
call perhaps?

Thanks, Shaheed

P.S. Is there a reason you prefer to use "EST" rather than "America/New_York"? 
Note that if you use the kcmshell clock to select the system timezone, it 
will always use an entry from zone.tab, and you will not have this problem.