[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: addition of generic timezone support to kdelibs
From:       Jason Harris <kstars () 30doradus ! org>
Date:       2005-07-06 5:12:58
Message-ID: 200507052212.58437.kstars () 30doradus ! org
[Download RAW message or body]

Hello,

> 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.
> 
I don't know what the local() function does, but I think that using the 
timezone of the closest city in the database will not work in many cases.  We 
may have to keep per-city timezone data in our Cities.dat file.

>         - 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.
Eventually having Windows support would be nice, but I wouldn't say I'm 
planning on it.  I don't know anything about the Windows API.

> 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?
Sounds good...thanks

Jason
-- 
KStars: KDE Planetarium
http://edu.kde.org/kstars
[prev in list] [next in list] [prev in thread] [next in thread]