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