Ankündigung

Einklappen
Keine Ankündigung bisher.

Diese verflixten Zeitzonen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Diese verflixten Zeitzonen

    Hi,

    ich habe ein Problem wo mir irgendwie der Ansatz fehlt.

    Mit meiner Applikation werden Techniker Einsätze für ganz EMEA geplant und dann ins CRM der Firma exportiert.
    Bisher war es so, dass das Backend (Das CRM der Firma) die Konvertierung für die Zeitzonen selber gemacht hat. Sprich ich habe in meiner Software verschiedene Ländermodule für alle Länder (bzw. teilweise auch mehrere Länder die gemeinsam verwaltet werden wie DACH) und wenn jemand in einem dieser Ländermodule wie z.B. Iberia einen Einsatz um 9:00 Uhr plant, dann exportiere ich den Einsatz mit der Zeit 9:00 und dem Ländercode. Somit wurde dann entsprechend der Einsatz immer zu richtigen Zeit geplant, bzw. der Anwender musste halt selber zusehen, dass wenn er, wie im Falle von Iberia 2 Zeitzonen hat (Spanien und Portugal), das er die Zeiten entsprechend passend umsetzt.

    Nun bekommt die Firma ein neues CRM und dieses erwartet beim Import immer UTC. Nun bin ich also der Dumme der sich mit den Zeitzonen herumschlagen muss. Generell kann ich natürlich erstmal eine Zeitzone für jedes Land setzen und entsprechend umrechnen. Problematisch wird es jetzt bei den Ländern die Sommer/Winterzeit haben. Ich muss ja dann entsprechend noch die 1 Stunde abziehen wenn Sommerzeit ist. Auch hier könnte man noch hergehen und mit irgendwelchen abstrusen Berechnungen herausfinden ob zu dem Zeitpunkt Sommer/Winterzeit ist aber das Ganze wird ja auch ständig geändert.

    Gibt es hier irgendwas out of the Box wo ich einfach jedes Datum und Uhrzeit (vor allem teilweise auch 2 Jahre in der Zukunft) in ein UTC wandeln kann und die eben auch ohne großen Wartungsaufwand sich aktualisieren wenn irgendwelche Politiker entscheiden doch wieder was zu ändern? Also quasi eine API die ich aber auch offline nutzen kann und halt nur einmal im Monat automatisch update?

    Gruß

    Claus
    Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

  • #2
    Du hast ein ganz anderes Problem. Ein Land kann mehrere Zeitzonen haben. Also allein vom Land kann man nicht auf die Zeitzone schließen. Dir muss irgendjemand die Zeitzone (oder zumindest die Geoposition) bekannt geben, ansonsten ist das ein unlösbares Problem.

    Aber wenn du mal die Zeitzone kennst, ist das eigentlich ein Spaziergang. Die DateTime-Klasse von PHP kann mit Zeitzonen umgehen und jede Zeitzone auf UTC umrechnen.

    Kommentar


    • #3
      Ok, Geodaten sind da. Also bräuchte ich eine Tabelle die mir von geodaten zu Zeitzone konvertiert und dann kann ich mit PHP daraus eine UTC Zeit machen. Aber die Zeitzonen sind ja dann auch unterschiedlich. Also im Sommer habe ich „Europe/Paris Day Saving time“ und I’m winter nur „Europe/Paris“ oder?
      Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

      Kommentar


      • #4
        Das Speichern von UTC Zeiten in einer DB macht durchaus Sinn, du hast ja selbst schon Argumente geliefert. Wie hellbringer schrieb kannst du die Ausgabe dann in der entsprechenden Zeitzone durch PHP erledigen lassen, da werden dann Sommerzeiten schon berücksichtigt.

        Mache nicht den Fehler die lokalen Zeiten zu nehmen und dann eine Spalte für Zeitzone, denn selbst die ändern sich ab und zu, so könnte man sich vorstellen, dass Spanien den Kanaren eines Tages die gleiche Uhrzeit vorgibt wie dem Festland. Kanaren haben derzeit MEZ -1, also wie Portugal oder GB.

        Kommentar


        • #5
          Ok, gehen wir das ganze mal von der anderen Seite an. Sagen wir der User kann seine Zeitzone einstellen und die speichere ich dann. Dann könnte ich mit PHP das problemlos umwandeln in UTC? Was genau passiert da mit der DST? Weiß PHP das auch? Also nehmen wir mal an der User wählt „Europe/Paris DST“ aus, würde PHP dann entsprechend die Zeiten berechnen je nachdem ob der Job in die Sommer- oder Winterzeit fällt? Und wie funktioniert das wenn sich da was ändert? Ich denke dann muss man PHP Updaten oder wie darf ich mir das vorstellen?
          Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

          Kommentar


          • #6
            Zitat von Thallius Beitrag anzeigen
            Ok, gehen wir das ganze mal von der anderen Seite an. Sagen wir der User kann seine Zeitzone einstellen und die speichere ich dann. Dann könnte ich mit PHP das problemlos umwandeln in UTC?
            ja, siehe https://www.php.net/manual/de/book.datetime.php

            Zitat von Thallius Beitrag anzeigen
            Was genau passiert da mit der DST? Weiß PHP das auch? Also nehmen wir mal an der User wählt „Europe/Paris DST“ aus, würde PHP dann entsprechend die Zeiten berechnen je nachdem ob der Job in die Sommer- oder Winterzeit fällt? Und wie funktioniert das wenn sich da was ändert? Ich denke dann muss man PHP Updaten oder wie darf ich mir das vorstellen?
            Man muss PHP nicht selbst updaten, wenn PHP auf dem Server läuft, der zu einem WEBSpace gehört. Dieser ist das meist unter UNIX, da wird die Zeitzonendatei automatisch aktualisiert, sofern du keinen eigenen Server betreibst.
            PHP lokal sollte man immer aktuell halten, also Updates aufspielen.

            Um den Rest den du erwähnst musst du dich dann nie mehr kümmern.

            Kommentar


            • #7
              Zitat von Thallius Beitrag anzeigen
              Ok, Geodaten sind da. Also bräuchte ich eine Tabelle die mir von geodaten zu Zeitzone konvertiert und dann kann ich mit PHP daraus eine UTC Zeit machen. Aber die Zeitzonen sind ja dann auch unterschiedlich. Also im Sommer habe ich „Europe/Paris Day Saving time“ und I’m winter nur „Europe/Paris“ oder?
              Sommer- und Winterzeit sind nicht zwei verschiedene Zeitzonen, das ist ein und die selbe. Zum Beispiel die Zeitzone in Deutschland ist Europe/Berlin, im Sommer UND im Winter. Es ändert sich nur der Offset, aber nicht die Zeitzone.

              Um die Zeitzone anhand einer Geolocation zu ermitteln gibt es verschiedene Libraries. Mein erster Treffer mit Google war die hier:

              https://github.com/minube/geo-timezone

              Aber das ist keine Empfehluing, da kannst ja selber mal rumschauen, was es da so gibt.

              Hier ein Beispiel für die Umrechnung:
              PHP-Code:
              $dateTime = new DateTime('2021-03-27 12:00', new DateTimeZone('Europe/Berlin'));
              echo 
              $dateTime->format('c') . PHP_EOL// 2021-03-27T12:00:00+01:00
              $dateTime->setTimeZone(new DateTimeZone('UTC'));
              echo 
              $dateTime->format('c') . PHP_EOL// 2021-03-27T11:00:00+00:00

              $dateTime = new DateTime('2021-03-28 12:00', new DateTimeZone('Europe/Berlin'));
              echo 
              $dateTime->format('c') . PHP_EOL// 2021-03-28T12:00:00+02:00
              $dateTime->setTimeZone(new DateTimeZone('UTC'));
              echo 
              $dateTime->format('c') . PHP_EOL// 2021-03-28T10:00:00+00:00 

              Kommentar


              • #8
                Zitat von protestix Beitrag anzeigen

                Man muss PHP nicht selbst updaten, wenn PHP auf dem Server läuft, der zu einem WEBSpace gehört. Dieser ist das meist unter UNIX, da wird die Zeitzonendatei automatisch aktualisiert, sofern du keinen eigenen Server betreibst.
                PHP lokal sollte man immer aktuell halten, also Updates aufspielen.

                Um den Rest den du erwähnst musst du dich dann nie mehr kümmern.
                Die Firma arbeitet in der Medizintechnik. Da ist gar nix in einem öffentlichen Webspace oder wird gar irgendwas automatisch geupdated. Da muss alles erstmal von der globalen IT validieret werden bevor es geändert werden darf. Wir arbeiten immer noch mit PHP7 auf unseren Servern... aber das ist ein anderes Thema...
                Pre-Coffee-Posts sind mit Vorsicht zu geniessen!

                Kommentar


                • #9
                  Zitat von Thallius Beitrag anzeigen
                  Ok, gehen wir das ganze mal von der anderen Seite an. Sagen wir der User kann seine Zeitzone einstellen und die speichere ich dann.
                  Das kommt auf den Use Case drauf an. Du schreibst was von Technikereinsätzen. Dann würde ich gegenüber des Users immer mit der Ortszeit der jeweiligen Location arbeiten. Es spielt dann im Prinzip auch keine Rolle ob du das intern als UTC oder lokale Zeit speicherst. Wenn du bisher mit der lokalen Zeit auskommen bist, ist das im Zweifel nur eine Export-Thematik.

                  Zitat von Thallius Beitrag anzeigen
                  Dann könnte ich mit PHP das problemlos umwandeln in UTC? Was genau passiert da mit der DST? Weiß PHP das auch? Also nehmen wir mal an der User wählt „Europe/Paris DST“ aus, würde PHP dann entsprechend die Zeiten berechnen je nachdem ob der Job in die Sommer- oder Winterzeit fällt?
                  Wenn ist das Europe/Paris. Solange du mit den "benannten" Zeitzonen arbeitest, ist Sommerzeit/Winterzeit kein Problem. Deswegen gibts die. In den IANA Daten (die werden auf *nix Systemen verwendet und z.B. auch von MySQL) hast du für die letzten 100 Jahre alle Regeln hinterlegt und auch alle Zukünftig bereits entscheidenen Änderungen.
                  Was du nicht machen darfst ist mit Offsets zu arbeiten. Ein +0100 gibt keine Auskunft ob Sommerzeit/Winterzeit.

                  Zitat von Thallius Beitrag anzeigen
                  Wir arbeiten immer noch mit PHP7 auf unseren Servern...
                  Naja... release von PHP 8 war vor 4 Monaten.

                  Kommentar


                  • #10
                    Meinen Erfahrungen nach, und ich habe schon mehrere Sachen mit Time und Date und UTC und Timezones gemacht, ist das Beste, immer mit Timestamp in UTC 0 zu rechnen. Also den Input in UTC 0 umwandeln und dann zu einem Timestamp machen und dann mit diesem rechnen. Die Zeitverschiebung in eine extra Variable, und auch die eventuelle Sommerzeit in eine Variable. Diese beiden Variablen dann nach dem rechnen hinzu addieren. Der Timestamp, der Wert der Zeitverschiebung und der Wert der eventuellen Sommerzeit-Zeitzone kann auch in eine Datenbank gespeichert werden.

                    Deine hauptsächliche Frage war aber eher, wie du an die Zeitwerte heran kommst. Da kannst du entweder die vom Browser/Device übermittelten Daten verwenden, oder fragst den User danach. Falls dieser sich ab und an woanders aufhält, müssen die Angaben korrigiert werden können. Also ist es praktisch, wenn die Angaben immer auch dem User angezeigt werden, damit dieser diese gegenprüfen kann. Dann kannst du auch die vom Browser/Device übermittelten Daten als default verwenden.

                    Es kommt nun nur darauf an, inwieweit du Manipulationen zulässt. Darf ein User eine beliebige Zeitzone eventuell mit Sommerzeit eingeben, oder willst du das weitgehend nach dem Wahrheitsgehalt kontrollieren? Wenn du dem User vertraust, dann nimmt die vom Browser/Device übermittelten Werte und biete dem User eine Manipulation an. Dabei kannst du den Timestamp vom Server nehmen und fügst die Angabe der Zeitzone und der eventuellen Sommerzeit hinzu. Oder du lässt den User auch den Timestamp manipulieren.

                    Feste Zeiten, also zB Arbeitsbeginn und Arbeitsende, als 3 Werte abspeichern: Timestamp, Zeitzonenwert, Sommerzeitwert. Somit bist du auch in Zukunft flexibel in der Berechnung und der Darstellung dieser Zeiten. Zudem können jeweils verschiedene Zeitzonenwerte und Sommerzeitwerte mit gespeichert werden. zB wenn ein IT-ler heute in Warschau und morgen in Washington DC arbeitet. Oder wenn er in Bewegung arbeitet (Flugzeug, Schiff), dann sind Zeitzonenwerte und Sommerzeitwerte nur Werte zur Anzeige der Zeit, aber nicht zur Berechnung der Arbeitszeit.

                    Kommentar


                    • #11
                      Zitat von psoido Beitrag anzeigen
                      Meinen Erfahrungen nach, und ich habe schon mehrere Sachen mit Time und Date und UTC und Timezones gemacht, ist das Beste, immer mit Timestamp in UTC 0 zu rechnen. Also den Input in UTC 0 umwandeln und dann zu einem Timestamp machen und dann mit diesem rechnen. Die Zeitverschiebung in eine extra Variable, und auch die eventuelle Sommerzeit in eine Variable. Diese beiden Variablen dann nach dem rechnen hinzu addieren. Der Timestamp, der Wert der Zeitverschiebung und der Wert der eventuellen Sommerzeit-Zeitzone kann auch in eine Datenbank gespeichert werden.
                      Erweitere deine Erfahrung um die DateTime-Klasse. Die ist in jeder Hinsicht besser in diesem Szenario.
                      Keine extra Variablen, kein extra dazu-addieren und vor allem: keine Timestamps.

                      Zitat von psoido Beitrag anzeigen
                      Deine hauptsächliche Frage war aber eher, wie du an die Zeitwerte heran kommst. Da kannst du entweder die vom Browser/Device übermittelten Daten verwenden, oder fragst den User danach. Falls dieser sich ab und an woanders aufhält, müssen die Angaben korrigiert werden können. Also ist es praktisch, wenn die Angaben immer auch dem User angezeigt werden, damit dieser diese gegenprüfen kann. Dann kannst du auch die vom Browser/Device übermittelten Daten als default verwenden.
                      Die Kultur-Daten ("locale") sind gut für die Formatierung von Datumswerten oder für die Sprache, die initial angezeigt werden könnte.
                      Für die Zeitzone, in der ich mich befinde, funktioniert das weniger gut, weil ich mich eben in einer ganz anderen Zeitzone zu den eingestellten Spracheinstellungen befinden könnte. Viele Länder haben nur eine Zeitzone und wenn man statistisch davon ausgeht, dass die meisten User auch gerade in dem Land sind, welches navigator.languages an Position 1 meldet, dann würde das wahrscheinlich schon ziemlich gut passen. Was zeigst du dann für eine Zeitzone in den Ländern an, die mehr als eine Zeitzone haben.

                      Zitat von psoido Beitrag anzeigen
                      Es kommt nun nur darauf an, inwieweit du Manipulationen zulässt. Darf ein User eine beliebige Zeitzone eventuell mit Sommerzeit eingeben, oder willst du das weitgehend nach dem Wahrheitsgehalt kontrollieren? Wenn du dem User vertraust, dann nimmt die vom Browser/Device übermittelten Werte und biete dem User eine Manipulation an. Dabei kannst du den Timestamp vom Server nehmen und fügst die Angabe der Zeitzone und der eventuellen Sommerzeit hinzu. Oder du lässt den User auch den Timestamp manipulieren.
                      Wenn ich es richtig verstanden habe, dann gibt es zu jedem Nutzer ohnehin einen User-Account.
                      Evtl. sollte man noch anbieten, die Zeitzone für eine gemeldete Zeit abweichend einstellen zu können, damit man fremde Zeitzonen nicht erst selbst in die eigene Zeitzone umrechnen muss.

                      Zitat von psoido Beitrag anzeigen
                      Feste Zeiten, also zB Arbeitsbeginn und Arbeitsende, als 3 Werte abspeichern: Timestamp, Zeitzonenwert, Sommerzeitwert. Somit bist du auch in Zukunft flexibel in der Berechnung und der Darstellung dieser Zeiten. Zudem können jeweils verschiedene Zeitzonenwerte und Sommerzeitwerte mit gespeichert werden. zB wenn ein IT-ler heute in Warschau und morgen in Washington DC arbeitet. Oder wenn er in Bewegung arbeitet (Flugzeug, Schiff), dann sind Zeitzonenwerte und Sommerzeitwerte nur Werte zur Anzeige der Zeit, aber nicht zur Berechnung der Arbeitszeit.
                      Nein, braucht man alles nicht. Es reicht, wenn du einfach nur den UTC+0-Wert in die Datenbank schreibst - als DATETIME-Wert. Für jeden User, der sich einen Zeit-Wert aus der Datenbank holt, wird eine Zeitzonen-Konvertierung in die Zeitzone des Nutzers gemacht und beim zurückschreiben von Daten in die Datenbank, wird wieder der UTC+0-Wert genommen. Alles ganz easy.

                      PHP-Code:
                      <?php
                      $datetime 
                      '2021-05-02 08:45:00';

                      $dt = new DateTimeImmutable($datetime, new DateTimeZone('UTC'));
                      printf("%s\n"$dt->format('c')); // 2021-05-02T08:45:00+00:00

                      $dtLocal $dt->setTimezone(new DateTimeZone('Europe/Berlin'));
                      printf("%s\n"$dtLocal->format('c')); // 2021-05-02T10:45:00+02:00

                      $dtUTC $dt->setTimezone(new DateTimeZone('UTC'));
                      printf("%s\n"$dtUTC->format('c')); // 2021-05-02T08:45:00+00:00

                      Kommentar

                      Lädt...
                      X