Seite 1 von 1
[gelöst] QTime :Umwandlung von UTC nach Lokalzeit (ohne DST)
Verfasst: 28. September 2009 08:23
von chrislo1976
Hallo zusammen!
Hat jemand eine Idee wie man es verhindern kann, dass QTime bei der Umwandlung von UTC nach lokaler Zeit die DST (Sommer-/Winterzeit) berücksichtigt?
An und für sich ist es ja gut dass dies automatisch gemacht wird und man es nicht beeinflussen muss, aber in unserem speziellen Fall macht das jetzt Probleme.
Wenn es eine Funktion wie z.B. isDST() gäbe, könnte ich die Korrektur selbst vornehmen, aber ich habe nichts dergleichen finden können.
Wäre für jede Art Info und Hilfe dankbar!
Gruß,
Christian
Verfasst: 28. September 2009 08:40
von pfid
Wenn wir von Deutschland ausgehen, hast du im Sommer GMT+2, im Winter GMT+1. Was genau willst du bei deiner Konvertierung jetzt als Ergebnis haben? Wenn du keine DST willst, nimmst du UTC.
Oder versteh ich was falsch?
Verfasst: 28. September 2009 08:50
von chrislo1976
Wir speichern sämtliche Zeitangaben in der Datenbank als UTC, weil unser Programm von vorne herein daraus ausgelegt sein soll, in verschiedenen Zeitzonen ohne Probleme zu funktionieren.
Deshalb wird eine lokale Zeit vor dem Speichern in die DB in UTC gewandelt, und nach dem Laden aus der DB wieder in die jeweilige Lokalzeit.
Im Normalfall ist das ok so. Allerdings haben wir jetzt Probleme (oder besser gesagt einen Umstand der uns nicht gefällt) bei dem Regelterminplaner in unserem Programm:
Wenn ich einen Regeltermin erstelle, sagen wir mal jeden 4. Freitag, kann ich auch Uhrzeiten angeben, von wann bis wann der Termin stattfinden soll. Problem ist jetzt, dass sich diese Uhrzeiten um 1 Std. verschieben wenn ein Wechsel von Sommer- nach Winterzeit und umgekehrt stattfindet.
Im Normalfall würde man so einen Regeltermin wohl immer zu selben Zeit machen, egal ob Sommer- oder Winterzeit herrscht...
Wir würden das gerne verhindern, oder noch besser es dem Bediener auswählen lassen können, ob diese "Zeitverschiebung" berücksichtigt werden soll oder nicht.
Ich hoffe ich konnte unser Anliegen etwas besser beleuchten...
Gruß,
Christian
Verfasst: 28. September 2009 09:43
von pfid
Ja, nun hast dus gut beleuchtet
Nimmst du QTime, oder QDateTime? Wenn letzteres, dürfte isDst() nur ein Einzeiler sein.
Verfasst: 28. September 2009 09:50
von chrislo1976
Wenn letzteres, dürfte isDst() nur ein Einzeiler sein.
Need more data...
Verfasst: 28. September 2009 10:22
von pfid
Gut, ein mehrzeiliger Einzeiler, pseudo:
Code: Alles auswählen
int isDst(localtime)
{
utc = toutc(localtime);
utc.setmonth(monat_in_dst);
localtime2 = utc.tolocal();
return localtime2.time() == localtime.time();
}
Wäre jetzt meine erste Idee.
Verfasst: 28. September 2009 11:19
von chrislo1976
@pfid
Ich habe jetzt deine erste Idee in das hier umgebaut:
Code: Alles auswählen
int isDst(QDateTime utc)
{
// given DateTime is/has to be UTC
utc.setTimeSpec(Qt::UTC);
// convert given DateTime to LocalTime
QDateTime t1 = utc.toLocalTime();
// change month of given DateTime to January,
// because there's no summer time
QDate d = utc.date();
d.setDate(utc.date().year(), 1, utc.date().day());
utc.setDate(d);
// ...and also convert that time to LocalTime
QDateTime t2 = utc.toLocalTime();
// If this time's are different, the given
// DateTime is in DST
return t1.time() != t2.time();
}
Damit kann ich erkennen ob die übergebene Zeit in der Sommerzeit liegen wird wenn sie in die Lokalzeit umgewandelt wird. Wenn ja kann ich dann die umgewandelte Zeit ggf. korrigieren.
Ich setz' den Thread mal noch nicht auf gelöst, denn ich möchte erst noch weiter testen, und evtl. hat ja jemand anders Einwände oder noch Verbesserungen...
Bis hier schon mal recht vielen Dank!
Verfasst: 28. September 2009 14:20
von chrislo1976
Hallo!
Also, ich hab jetzt noch einiges getestet, und eigentlich keine Probleme mehr gefunden.
Was ich mir vorstellen könnte was noch ein Problem machen könnte, ist die feste Annahme dass im Januar immer Winterzeit herrscht. Da werd ich wohl noch ein wenig "forschen" müssen um rauszufinden ob das irgendwie/irgendwo ein Problem werden kann...
Gruß,
Christian
Verfasst: 29. September 2009 13:06
von FaS
Das hängt wohl davon ab, wo die Sonne grad unterwegs ist: Auf der Südhalbkugel ist im Januar Sommer.
Ist doch außerdem verwirrend, wenn jemand im Sommer 13:00 einstellt und aufeinmal geht das um 12:00 an. Dann besser nur UTC verwenden, dann ist das halt 1-2h verschieden (hier zumindest) statt 0-1h, aber dafür nachvollziehbar. Und du kannst beim Einstellen der Uhrzeit ja parallel die zugehörige Lokalzeit anzeigen lassen.
Verfasst: 29. September 2009 13:15
von chrislo1976
Hallo!
Ist doch außerdem verwirrend, wenn jemand im Sommer 13:00 einstellt und aufeinmal geht das um 12:00 an.
Genau um das ging es ja...
Mitunter durch die Funktion isDst() ist es jetzt so dass eine Zeit eines Termins immer gleich bleibt, egal ob Sommer- oder Winterzeit. Es ist auch egal ob der Termin ursprünglich im Sommer oder im Winter angelegt wurde.
Einmal 12 Uhr, immer 12 Uhr!
In einer anderen Zeitzone allerdings wird aus 12 Uhr aber schon eine andere Zeit, je nach Zeitverschiebung.
Gruß,
Christian
Verfasst: 29. September 2009 13:22
von FaS
Nein. Wenn du die Sommerzeit wegkorrigierst stimmt die Zeit nicht mit der vom Beobachter erwarteten Zeit überein: Auf dem Plan steht 13, an geht das um 12. Durch deine Korrektur ist lediglich die Zeitdifferenz zu 2 Terminen identisch.
Und Januar=Sommerzeit kannst du wie gesagt nicht so lassen.
Es ist auch egal ob der Termin ursprünglich im Sommer oder im Winter angelegt wurde.
Einmal 12 Uhr, immer 12 Uhr! Smile
Moment, das trifft doch nur zu, wenn du die Lokalzeit benutzt, also mit DST. Wenn es wirklich nur darum geht, dass die Maschine nicht verwirrt wird, musst du UTC nehmen.
Was du noch beachten musst: Wandelst du UTC in die Lokalzeit um, ist die resultierende Zeit unabhängig von der aktuellen Sommer-/Winter-Situation.
Verfasst: 29. September 2009 13:38
von chrislo1976
Ich will dir jetzt mal nicht (vollständig) widersprechen, evtl. verstehe ich ja nicht alles was du geschrieben hast.
ABER: Wie gesagt, jetzt tut unser Terminplaner genau das was er tun soll. VORHER hatte ich Probleme dass die Uhrzeiten um 1 bzw. 2 Stunden verschoben waren!
Wandelst du UTC in die Lokalzeit um, ist die resultierende Zeit unabhängig von der aktuellen Sommer-/Winter-Situation.
Warum ergibt dann:
Code: Alles auswählen
QDateTime dt1 = QDateTime(QDate(2009,1,29), QTime(14,0,0), Qt::UTC);
qDebug() << dt1.toLocalTime().toString();
QDateTime dt2 = QDateTime(QDate(2009,9,29), QTime(14,0,0), Qt::UTC);
qDebug() << dt2.toLocalTime().toString();
das:
"Do 29. Jan 15:00:00 2009"
"Di 29. Sep 16:00:00 2009"
Es müsste doch laut deiner Aussage beide Male die gleiche Uhrzeit ausgegeben werden?!
Verfasst: 29. September 2009 13:51
von FaS
Ich glaube ich habe dein Problem nicht richtig verstanden, d.h. wo genau die Differenzen auftreten und aus welcher Perspektive. Deine Zeitangaben scheinen außerdem garnicht Datumsabhängig zu sein..
Naja wie auch immer. Mit meiner letzten Aussage meine ich, dass QDateTime(QDate(2009,1,29), QTime(14,0,0), Qt::UTC) im Sommer wie im Winter in Lokalzeit "Do 29. Jan 15:00:00 2009" ergibt. Ist wohl klar. Aber diese Tatsache kam mir als Hindernis vor. Den Sinn mit diesen komischen Sommerwegrechnungen aber trotzdem auf Lokalzeit beharren habe ich noch nicht verstanden, und glaube nicht, dass das eine gute Lösung ist. Aber musst du besser wissen. Ggf. irgendwie das Datum, an dem der Plan "jeden 4. Freitag" erstellt wurde, mitbenutzen..
MfG,
FaS