On Sunday 06 April 2008 01:48:01 Frank Hemer wrote:
> > 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.
> That would definitely be better. Still this is not a solution for critical
> applications like mine.
Well, for critical applications I would not trust any kind of timezone database.
The only thing that sort-of-works is to fix a 0 and count "real" seconds from
there. Any "translation" into "human readable form" using month, days and
hours is bound to fail rather sooner then later - not to mention using such
a format as "primary data".
Recently there was this discussion on the Gregorian changes, which took
300 years to spread across Europe alone. No way to handle that reliably...
> > Anyways, that explains why you got different values:
> > 1) QDateTime applied the rules for Jan 1st 1970 for your June 1947 date.
1947... well, there was a time when part of Germany had Moscow time.
Not sure this bites here, but it's not unlikely.
Incidentally, that boundary between Moscow and (something like) Central
European Time within Germany at that time did _not_ coincide with the
later border between East and West Germany.
So to get "proper" "time" you'd need not only need the GPS data of frontline
Russian and American tanks around May 9, 1945 (give or take a few days,
and kilometers, ...) but also take into account the speed and willingness
of local commanders setting up townhall clocks ;-)
To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
"unsubscribe" in the subject or the body.
List archive and information: http://lists.trolltech.com/qt-interest/