RFC: addition of generic timezone support to kdelibs

Shaheed srhaque at iee.org
Wed Jul 6 06:14:15 BST 2005


Jason wrote:

>In KStars, we have our own internal representation of timezones, so I'm 
>definitely interested in using this class.  How are you handling the various 
>"daylight savings" rules?  I guess unix zoneinfo takes care of it?  Anway, 
>just in case you need it, our code is here:

Thanks for the pointer. AFAICS, yes, the zoneinfo files do contain the info 
that seems to be in your database file (try "man tzset()" for format info).

I do have to consider in a bit more detail your association with 
city/location: the good news is that since you have lattitude/longitude info, 
and I support that, you should be able to lookup timezone info by either 
"closest" timezone, or using the local() function depending on what you need 
for cities not named in the zoneinfo database. Note that Solaris' lack of 
zone.tab means it is missing the geographical info.

Some questions to consider for both you and Reinhard:

	- Do you plan to be portable to Windows at some point?

	- If so, do you know if the corresponding Windows API has the information you
	seek? If not, I have tried to structure the APIs that we could #ifdef your
	(combined) database files as a fallback but I'm unlikely to do that work
	myself.

Anyway, if you think this is a likely direction for either of you, I have 
worked out how I would support you. I would:

1. Slightly refactor the current API to make KTimezone() constructor only 
accessible to KTimezones. This should be invisible to all users.

2. Implement a KTimezoneReader class with virtual method "callbacks". You 
would override the methods you cared about to get the info you wanted.

How does all that sound? Shaheed

P.S. Please keep the CC to me on replies.




More information about the kde-core-devel mailing list