[gelöst] QTime :Umwandlung von UTC nach Lokalzeit (ohne DST)

chrislo1976 · Beitrag von **chrislo1976** » 28. September 2009 08:23

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

pfid · Beitrag von **pfid** » 28. September 2009 08:40

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?

chrislo1976 · Beitrag von **chrislo1976** » 28. September 2009 08:50

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

pfid · Beitrag von **pfid** » 28. September 2009 09:43

Ja, nun hast dus gut beleuchtet

Nimmst du QTime, oder QDateTime? Wenn letzteres, dürfte isDst() nur ein Einzeiler sein.

chrislo1976 · Beitrag von **chrislo1976** » 28. September 2009 09:50

Wenn letzteres, dürfte isDst() nur ein Einzeiler sein.

Need more data...

pfid · Beitrag von **pfid** » 28. September 2009 10:22

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.

chrislo1976 · Beitrag von **chrislo1976** » 28. September 2009 11:19

@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!

chrislo1976 · Beitrag von **chrislo1976** » 28. September 2009 14:20

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

FaS · Beitrag von **FaS** » 29. September 2009 13:06

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.

chrislo1976 · Beitrag von **chrislo1976** » 29. September 2009 13:15

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

FaS · Beitrag von **FaS** » 29. September 2009 13:22

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.

chrislo1976 · Beitrag von **chrislo1976** » 29. September 2009 13:38

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?!

FaS · Beitrag von **FaS** » 29. September 2009 13:51

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