Zeitstempel mit Zeitzoneninformation

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

  • Zeitstempel mit Zeitzoneninformation

    Hallo zusammen,

    ich möchte gerne Zeitstempel mit Zeitzoneninformationen in die Datenbank legen und mit PHP verarbeiten. An sich kein Problem. Die Frage die sich mir stellt ist, wie die allgemeine Unterstützung von Zeitstempeln mit Zeitzoneninformationen in den verschiedenen Datenbanksystemen ist, vor allem bei MySQL, Oracle und MS SQL Server.
    Meine ersten Recherchen haben ergeben, dass MySQL Zeitstempel intern in UTC speichert und entsprechend der an der Verbindung eingestellten Zeitzone beim Schreiben und Lesen konvertiert.
    Bei Oracle gibt es den Datentyp TIMESTAMP WITH TIME ZONE, was perfekt erscheint.
    Bei MS SQL Server habe ich nichts zu Zeitzonenunterstützung gefunden und gehe davon aus, dass hier die Zeitzone des Betriebssystems genutzt wird und keinerlei Änderungen am Zeitstempel vorgenommen werden.

    Zusammenfassend gibt es keine DBMS-weite Unterstützung von Zeitstempeln mit Zeitzoneninformationen.
    Darum stellt sich mir jetzt die Frage, wie ihr so etwas handelt. Ich könnte mir vorstellen, alle Zeitstempel vor dem Schreiben in UTC zu konvertieren und zusätzlich zu jedem Zeitstempel noch die Zeitzone abzuspeichern. Aber vielleicht habt ihr da ja einen geschmeidigeren Weg für mich Ich freue mich auf Hinweise.

  • #2
    Eine Zeitzone ist ja nur ein Offset zu einem Zeitstempel, der dafür sorgt, dass der Betrachter den Zeitstempel in "seiner" Zeit angezeigt bekommen kann.
    Du kannst also alle Zeitstempel in derselben Zeitzone speichern, bspw. UTC. Wenn du vom aktuellen Benutzer weißt, in welcher Zeitzone er lebt, kannst du jeden Zeitstempel so umrechnen, dass es seiner Lokalzeit entspricht. Hast du vom aktuellen Benutzer keine Zeitzone, benutzt du die Standardzeitzone deiner Seite.
    Um möglichst wenig rechnen zu müssen, empfiehlt es sich daher, alle Zeitstempel in der Standardzeitzone der Seite zu speichern.

    Anhand eines Beispiel ist es verständlicher:
    Angenommen du hast ein Blog, in dem jemand einen Kommentar postet. Du möchtest den Zeitpunkt des Posts festhalten und später mit dem Kommentar zusammen anzeigen.
    Dein Blog ist deutsch, deine Standardzeitzone ist dementsprechend GMT+1. Sommer-/Winterzeit (DST) lassen wir erstmal außen vor.
    Ist der Kommentator eingeloggt, ist in seinem Profil im Idealfall seine Zeitzone festgelegt. Nehmen wir an es wäre GMT+3, irgendwo in Russland.
    Der Kommentar wird 12 Uhr GMT+1 abgeschickt. Genau das speicherst du auch in der DB.
    Der Russe bekommt seinen Kommentar nun gleich wieder angezeigt. Dazu verrechnest du den Zeitstempel des Kommentars, also 12 Uhr GMT+1 mit der Zeitzone aus seinem Userprofil GMT+3, addierst also 2 Stunden dazu, so dass der Russe 14 Uhr angezeigt bekommt.
    Nun kommt ein anonymer Benutzer auf deine Seite. Von dem weißt du erstmal nicht wo er wohnt. (Du kannst anhand seines Requests (Accept-Language) eine Zeitzone bestimmen. Aber das lassen wie ebenfalls mal außen vor.) Du zeigst den unveränderten Zeitstempel 12 Uhr an.
    Zuletzt geändert von onemorenerd; 23.04.2010, 17:43.

    Kommentar


    • #3
      Zitat von onemorenerd Beitrag anzeigen
      Nun kommt ein anonymer Benutzer auf deine Seite. Von dem weißt du erstmal nicht wo er wohnt. (Du kannst anhand seines Requests (Accept-Language) eine Zeitzone bestimmen.
      Wie soll denn das funktionieren ...?

      Selbst wenn wir mal davon ausgehen, dass du nicht nur sowas wie "en" kriegst, was praktisch überall auf der Welt bedeuten kann, sondern etwas spezifischeres wie bspw. "en-us", sind das immer noch mehrere Zeitzonen.

      Über die IP auf die Geo-Location zu schliessen und davon auf die Zeitzone, wäre noch halbwegs vorstellbar, wenn auch nicht unbedingt zuverlässig.
      I don't believe in rebirth. Actually, I never did in my whole lives.

      Kommentar


      • #4
        Es gibt Werte von Accept-Language, die sich genau einer Zeitzone zuordnen lassen. So zum Beispiel de. Bei en geht das nicht. Dann muss man doch mit GeoIP oder JS-Cookie nachhelfen. Diese beiden Verfahren sind aber nicht perfekt - manche User haben kein JS, akzeptieren keine Cookies, sind in keiner GeoIP-DB zu finden oder tunneln sich über mehrere Kontinente. Deshalb sollte sollte man es zuerst mit Accept-Language versuchen. Wenn das nicht auf eine Zeitzone schließen lässt, versucht man es weiter mit JS oder GeoIP … und wenn alles nicht hilft, kann man auch noch den User fragen.

        Kommentar


        • #5
          Zitat von onemorenerd Beitrag anzeigen
          Es gibt Werte von Accept-Language, die sich genau einer Zeitzone zuordnen lassen. So zum Beispiel de. Bei en geht das nicht. Dann muss man doch mit GeoIP oder JS-Cookie nachhelfen. Diese beiden Verfahren sind aber nicht perfekt - manche User haben kein JS, akzeptieren keine Cookies, sind in keiner GeoIP-DB zu finden oder tunneln sich über mehrere Kontinente. Deshalb sollte sollte man es zuerst mit Accept-Language versuchen. Wenn das nicht auf eine Zeitzone schließen lässt, versucht man es weiter mit JS oder GeoIP … und wenn alles nicht hilft, kann man auch noch den User fragen.
          Was ist, wenn jemand mit seinem Laptop, der auf de_DE gestellt ist, in Amerika ist?

          Oder wenn jemand in Deutschland/Österreich ein englisches Betriebssystem mit englischem Browser verwendet? zB. so wie ich.

          Kommentar


          • #6
            Zitat von onemorenerd Beitrag anzeigen
            Du kannst also alle Zeitstempel in derselben Zeitzone speichern, bspw. UTC. Wenn du vom aktuellen Benutzer weißt, in welcher Zeitzone er lebt, kannst du jeden Zeitstempel so umrechnen, dass es seiner Lokalzeit entspricht. Hast du vom aktuellen Benutzer keine Zeitzone, benutzt du die Standardzeitzone deiner Seite.
            Um möglichst wenig rechnen zu müssen, empfiehlt es sich daher, alle Zeitstempel in der Standardzeitzone der Seite zu speichern.
            Hmm, das ist in der Tat die einfachere Lösung. Danke, so werde ich es machen.
            Du kannst anhand seines Requests (Accept-Language) eine Zeitzone bestimmen. Aber das lassen wie ebenfalls mal außen vor.
            Könnte man versuchen, aber ich denke, da ist die Standardzeitzone durchaus ausreichend.

            Kommentar


            • #7
              Zitat von h3ll Beitrag anzeigen
              Was ist, wenn jemand mit seinem Laptop, der auf de_DE gestellt ist, in Amerika ist?
              Derjenige kann sicherlich mit Zeitangaben in seiner Heimat-Zeit mehr anfangen als mit Zeitangaben in der Standardzeitzone der Webseite.
              Stell dir mal vor, es ist eine chinesische Seite. Willst du dem Deutschen in Amerika lieber deutsche Zeitstempel zeigen, wie er sie auch zu Hause sehen würde, oder chinesische?

              Zitat von h3ll Beitrag anzeigen
              Oder wenn jemand in Deutschland/Österreich ein englisches Betriebssystem mit englischem Browser verwendet? zB. so wie ich.
              Du sprichst doch sehr gut deutsch, vermutlich ist es deine Muttersprache. Da drängt sich die Frage auf, warum du deinen Browser über deinen Kulturkreis falsche Auskunft geben lässt.


              Noch mal ganz deutlich: Um die Zeitzone eines Besuchers zu ermitteln hat man mehrere Möglichkeiten.

              1. Man fragt den User. Antwort speichert man
              1.a im Profil (klappt nur bei registrierten Benutzern)
              1.b als Cookie (klappt nur wenn Cookies erlaubt)

              2. Man schlägt in einer GeoIP-DB nach. (kann falsches oder gar kein Ergebnis liefern)

              3. Man nutzt Javascripts Date::getTimezoneOffset(). (klappt nur bei aktiviertem JS)

              4. Man nutzt Accept-Language. (klappt nur bei Sprachräumen, die komplett in einer TZ liegen)


              Aus diesen Möglichkeiten kann sich jeder aussuchen, welche für ihn bzw. seine User in Frage kommen bzw. in welcher Reihenfolge er diese Möglichkeiten als Fallbacks nutzen will.

              Ich würde es in dieser Reihenfolge versuchen: 1.a, 3, 1.b, 4, 2.
              Und ich lasse mir nicht einreden, dass es besser wäre, die 4 aus dieser Folge zu streichen.

              Kommentar


              • #8
                Zitat von onemorenerd Beitrag anzeigen
                Derjenige kann sicherlich mit Zeitangaben in seiner Heimat-Zeit mehr anfangen als mit Zeitangaben in der Standardzeitzone der Webseite.
                Wenn ich in Amerika bin, kann ich mit einer Angabe in lokaler Zeit, die mich darauf hinweist, dass ein Eintrag vor einer halben Stunde in lokaler Zeit gemacht wurde oder dass ein Event in vier Stunden stattfindet, sicherlich mehr anfangen, als wenn das in meiner Heimat-Zeitzone angegeben wäre, wo ich dann erst mal umrechnen müsste.
                Stell dir mal vor, es ist eine chinesische Seite. Willst du dem Deutschen in Amerika lieber deutsche Zeitstempel zeigen, wie er sie auch zu Hause sehen würde, oder chinesische?
                Kommt drauf an, in welchem Kontext ich diese Zeitstempel einordnen möchte.

                Dass der Chinese im Forum nach Mitternacht seiner Zeit gepostet hat, und deshalb Müdigkeitsfehler entschuldbar sind, ist eine Info, mit der ich im Zweifelsfalle mehr anfangen kann als damit, dass es um 9:47 oder 13:11 meiner Zeit war.

                Du sprichst doch sehr gut deutsch, vermutlich ist es deine Muttersprache. Da drängt sich die Frage auf, warum du deinen Browser über deinen Kulturkreis falsche Auskunft geben lässt.
                Je nachdem, wo ich surfe, habe ich teilweise auch en bzw. en-US als bevorzugte Sprachvariante eingestellt.
                Das ist u.a. hilfreich bei Seiten, die content negotiation nutzen, um mir die vermeintlich am besten passende Sprachversion zu liefern - dass z.B. mit dem PHP-Manual im englischen Original meist besser zu arbeiten ist, als mit der deutschen Übersetzung, ist doch kein Geheimnis. Und auch bei last.fm ziehe ich die englische Version vor, weil die Artist Descriptions dort meist deutlich informativer sind, als die rudimentären deutschen Artikel, die ich sonst automatisch vorgesetzt bekommen würde.
                Ob ich damit meinen „Kulturkreis“ verleugne, ist mir dabei reichlich egal. Meine Entscheidung basiert auf dem, was für mich generell den höheren Nutzen bringt.

                Noch mal ganz deutlich: Um die Zeitzone eines Besuchers zu ermitteln hat man mehrere Möglichkeiten.
                1 und 3 sind für mich dabei noch die sinnvollsten; der Rest eher Voodoo.

                Und ich lasse mir nicht einreden, dass es besser wäre, die 4 aus dieser Folge zu streichen.
                Kann man natürlich halten, wie man will.
                Ich persönlich halte es für so unzuverlässig, dass es nicht mal ansatzweise den Aufwand der Implementierung lohnt; für 2. ähnlich.


                Einige große „internationale“ Seiten (last.fm hatte ich ja schon als Beispiel) nutzen inzwischen ja schon das Prinzip, Zeitpunkte, die in der kürzeren Vergangenheit/näheren Zukunft liegen, nicht (nur) als Zeitangaben anzugeben, sondern halt als „vor drei Stunden“ oder „in dreißig Minuten“.
                Damit kann ich meistens sehr viel mehr anfangen, als mit Angaben in einer beliebig und ohne meinen Einfluss gewählten Zeitzone.


                (Aber wir kommen stark von der Thematik der ursprünglichen Fragestellung ab - da ging es ja vornehmlich um die Speicherung von Zeitangaben inkl. Zeitzone.)
                I don't believe in rebirth. Actually, I never did in my whole lives.

                Kommentar


                • #9
                  Zitat von wahsaga Beitrag anzeigen
                  Aber wir kommen stark von der Thematik der ursprünglichen Fragestellung ab - da ging es ja vornehmlich um die Speicherung von Zeitangaben inkl. Zeitzone.
                  In der Tat schweift ihr ab. Die Frage ist aber soweit geklärt, dass es wohl am sinnigsten ist, Zeitstempel in einer neutralen Zeitzone (UTC) in der Datenbank abzulegen und bei Ein- und Ausgaben entsprechend zu konvertieren. Zuletzt ist das mitunter auch der mangelnden Umsetzung von zeitzonenbehafteten Zeitstempeln in den verschiedenen DBMS geschuldet.

                  Von daher, schweift ruhig weiter ab, die Diskussion ist sehr interessant! Alternativ kann ein Mod das Thema ja auch in zwei Threads splitten

                  Kommentar


                  • #10
                    Zitat von PHP-Desaster Beitrag anzeigen
                    In der Tat schweift ihr ab. Die Frage ist aber soweit geklärt, dass es wohl am sinnigsten ist, Zeitstempel in einer neutralen Zeitzone (UTC) in der Datenbank abzulegen und bei Ein- und Ausgaben entsprechend zu konvertieren. Zuletzt ist das mitunter auch der mangelnden Umsetzung von zeitzonenbehafteten Zeitstempeln in den verschiedenen DBMS geschuldet.
                    In PostgreSQL wird jeder Zeitstempel mit einer Zeitzone abgespeichert.

                    Kommentar

                    Lädt...
                    X