lists at astrojar.org.uk
Fri May 19 21:32:44 BST 2006
In fixing a time zone related test program fail for KDateTime, I refreshed my
memory about some important limitations of the KSystemTimeZones class.
Basically, KSystemTimeZones is limited to what libc provides (which varies to
some extent between systems). Its limitations are:
1) It can't handle times before 1970, since it uses time_t to represent times.
2) On non-GNU systems where struct tm doesn't have a tm_zone member, it can
only return time zone abbreviations (such as "GMT", "EST") which are in
current use (i.e. those held in the TZ environment variable). If at some past
time a different abbreviation was used, there's no way of finding this out
using the library functions.
So, KSystemTimeZones can be used successfully cross-platform from 1970
onwards, provided that time zone abbreviations aren't accessed. If earlier
dates, or accurate time zone abbreviations are needed, you need to use
KTzfileTimeZone which directly accesses the system time zone database files.
But presumably using KSystemTimeZones will generally be more efficient than
using KTzfileTimeZone. But KTzfileTimeZone may not necessarily be applicable
to all platforms - e.g. Windows?
It is obvious that these limitations need to be highlighted in the
documentation. Is that sufficient to warn people off using it in the wrong
circumstances? It could be argued that the class is too liable to cause bugs,
and that its use should be discouraged. Any comments?
More information about the kde-core-devel