[PATCH] implementation of a timezone backend for Windows

David Jarvie djarvie at kde.org
Sun Feb 15 19:55:22 CET 2009


Hi Till,

On Saturday 14 February 2009 19:53:08 Till Adam wrote:
> On Saturday 14 February 2009 20:18:37 David Jarvie wrote:

> > The first question is, does Windows have alternative methods of accessing
> > time zone data? Unix allows time zone data to be accessed either by the
> > libc library or by accessing the tzfile data. The former provides more
> > limited data (and is used by KSystemTimeZone), while the latter provides
> > all the system knows about time zones at the expense of extra overhead
> > (and is used by KTzfileTimeZone). Your implementation would be suitable
> > if Windows provides only one data access method, or if it provides more
> > than one method but you're only using the 'easy' access method just now.
>
> Hm, it's the best and most complete we've found.
>
> > On the assumption that they provide the fullest information available on
> > Windows, I wonder whether the KSystemTimeZoneWindows classes could
> > perhaps be made publicly accessible in the same manner as the
> > Unix-specific KTzfileTimeZone classes. Just an idea.
>
> Hm, would that add anything?

If that's the only way being provided to access time zone data on Windows, 
then no. Just leave things as you proposed.

> > kdebase/runtime/ktimezoned/ktimezoned.cpp needs to have Windows code
> > added in the appropriate places as well. Or, if ktimezoned is by any
> > chance unnecessary on Windows, it should be disabled on that system.
>
> I actually have a patch for it, just forgot to attach it. It's:
>
> http://websvn.kde.org/branches/kdepim/enterprise4/kdebase-4.1-
> branch/runtime/ktimezoned/ktimezoned.cpp?r1=849447&r2=920715

There is nothing to check for changes in the local time zone and emit a signal 
if a change is detected. That's one of the main functions of ktimezoned. There 
is also no check for changes in time zone definitions - again a signal should 
be emitted if a change is detected. The latter may of course be difficult to 
detect - if so, there should at least be a TODO marked in the code. The former 
really is necessary.

The other thing I would add is to #ifdef out all the functions which access 
zone.tab, in both the header and cpp files, since none of them will be 
applicable to Windows. It was a bit of an oversight that I didn't do that 
originally.

Cheers,
-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm



More information about the Kde-windows mailing list