KSystemTimeZones limitations

[David Jarvie]

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?

-- 
David Jarvie.