• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Datum im GMT Format

G

gammelfleisch

Neues Mitglied
Hallo,

ich habe ein Formular, welches über einen JQuery-Datepicker ein Datum einließt, diesen ins GMT Format unwandelt und per AJAX an einen Server sendet. Das Problem ist Folgendes:

Es ist gerade "Mon, 14 Nov 2011 17:34:14" Uhr, aber als Ausgabe steht natürlich "Mon, 14 Nov 2011 16:34:14 GMT", eben nach dem GMT Format. Gibt es eine Option, dass ich zwar den GMT String habe, aber mit der lokalen Uhrzeit? (also ohne den String selbst zu erstellen, sondern über z.B. 'nen Parameter)

Denn der Server nimmt diesen String in dieser Form und parst ihn. Er würde theoretisch somit alles eine Stunde früher schedulen (dafür braucht es das Datum).
 
gammelfleisch schrieb:
diesen ins GMT Format unwandelt und per AJAX an einen Server sendet ....
Es ist gerade "Mon, 14 Nov 2011 17:34:14" Uhr, aber als Ausgabe steht natürlich "Mon, 14 Nov 2011 16:34:14 GMT", eben nach dem GMT Format.
Zum Vergrößern anklicken....
Na wenn du GMT an den Server sendest, dann musst ja beim JQuery Aufruf was tun, um aus der lokalen Zeit eine GMT zu machen. Genau diesen Schritt musst beim Anzeigen rückgängig machen. Das ist natürlich bei Anwendungen, die über mehrere Länder gehen, nicht einfach, da du von jedem Client den Time-Offset (also die Zeitzone) kennen und berücksichtigen musst. Daher musst bei vielen Foren beispielsweise beim Registrieren deine Zeitzone angeben.
 
Ich hab mal folgendes Minimalbeispiel erstellt:
HTML: 
<html>
<head><title>Test</title></head>
<body>
<script type="text/javascript">
    var zeit = new Date();
    document.write(zeit + "<br>");
    document.write(zeit.toGMTString());
</script>
</body>
</html>

Die Ausgabe ist
Tue Nov 15 2011 01:27:32 GMT+0100
Tue, 15 Nov 2011 00:27:32 GMT
Zum Vergrößern anklicken....
@NetAktiv
Du meinst also, ich soll quasi bevor ich das Datum an den Server sende, es "plus 1" rechnen und dann erst "toGMTString()" aufrufen + senden? Gibt es dazu eine "elegante" Möglichkeit (statt wirklich arithmetisch plus eins zu rechnen)?
 
Ich meine, die meisten (internationalen) Anwendungen speichern GMT in der DB auf dem Server und zeigen dem Benutzer die lokale Zeit an. Das heißt, meist sendet die Client-Anwendung GMT an den Server, der muss sich dann um nichts kümmern und speichert die 1:1 ab. Soll aus den Server-Daten nach einem GET/POST Request des Benutzers eine HTML-Seite formatiert werden, dann muss auf dem Server die GMT in die lokale Zeit des Benutzers zurückgesetzt werden und dazu musst du die Zeitzone des Benutzers kennen (oder schätzen anhand von IP, Sprache, ...). Nur so schaffst du es, dass zwei Benutzer in verschiedenen Zeitzonen die gleichen Server-Daten richtig mit der lokalen Zeit angezeigt bekommen.

Bei den Daten kann es sich eh nur um Benutzereingaben handeln (wie genauer Geburtstag mit Uhrzeit), denn für Systemereignisse (wie Erstellzeitpunkt eines Datensatzes) kannst eh nur die Server-Uhrzeit nehmen, auf die Zeit auf dem PC kannst dich ja nicht verlassen.
 
Zuletzt bearbeitet:
Der Client sendet dem Server ein Datum im GMT Format (ist so vorgegeben). Der Server nimmt es entgegen, parst es und schedult einen Prozess entsprechend dem Datum, der dann auf dem Server läuft zum übertragenen Startdatum. Deswegen ist es für mich auch wichtig, dass die lokale Zeit beachtet wird und auf dem Server auch so vorliegt. Sonst startet der Prozess immer eine Stunde früher (und der Server ist bei mir im Untergeschoss :d).
 
Na, dann ist dein Server ja der 'Benutzer, der nach seiner Startzeit fragt', dann musst die Zeitzone des Servers kennen und aus GMT die lokale Zeit des Servers berechnen.
 
Deswegen ist es für mich auch wichtig, dass die lokale Zeit beachtet wird und auf dem Server auch so vorliegt.
Zum Vergrößern anklicken....

Die Aussage verstehe ich nicht.

Zeitdaten sollten aber immer in UTC (der genaue Unterschied zu GMT scheint eher technischer Natur zu sein) verwaltet werden und bei Bedarf in lokale Zeitzonen umgerechnet werden. Der Bedarf ist dabei praktisch immer die menschenlesbare Darstellung. Ich kann mir gerade keinen Fall denken, wo es für ein Programm intern relevant ist, ob es in UTC arbeitet oder in einer anderen Zeitzone.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben