Frank Hemer wrote:
>> >Well, so what chance do I have to convert the msecs to a valid date?
>> >time_t, as implemented in QDateTime doesn't help as it is only valid
>> > after the Epoche. Setting the value manually (QDateTime (QDate (y,
>> > m, d), QTime (h, m, s)), xxx) doesn't help either?
>> Use a full QDateTime (year, month, day, hour, minute and second) or
>> whatever makes sense to you. Dates of birth and timezones don't make
>> sense together.
>First, date of birth was just an example, second, date of birth comes
> with full date _and_ time info from the database - timezone info
> included. Its a medical database and the time of birth is a required
> info. So I have to handle it properly.
>Other timestamps _before_ 1970 also are stored in the same manner, so I
> have to implement a clean solution.
>Probably I have to implement timezone handling myself across platforms.
>Still I think this should be handled by QDateTime ...
QDateTime handles only two timezones: Local and UTC. And it works fine
The conversion between them requires information from the timezone
database. On Unix systems, that database contains historical information,
so all past dates should be correct. Unfortunately, that database uses
time_t, so it has to be a positive value because some Unix systems have
an unsigned time_t.
If a data falls outside the range of positive values in a 32-bit signed
time_t, QDateTime will use the lowest or highest values (Jan 1st 1970 or
Jan 19, 2038). The idea there is that we'll at least get the offset from
GMT right, even if the DST information was lost.
But, come to think of it, we can do better: use the same day and month,
but the lowest or highest year (1970 or 2037). At least there's a higher
chance of getting DST right.
Anyways, that explains why you got different values:
1) QDateTime applied the rules for Jan 1st 1970 for your June 1947 date.
2) In January 1970, Berlin was most likely in Central European Time
3) In June 1947, Berlin was likely in Summer Time. But you're seeing 3
hours ahead of GMT, which is either Double Summertime or Berlin was in a
different timezone then.
4) you're assuming that the negative time_t worked with localtime().
Thiago José Macieira - thiago.macieira AT trolltech.com
Trolltech ASA - Sandakerveien 116, NO-0402 Oslo, Norway