Moin!
genau das ist falsch.
Oh, Vorsicht mit so absoluten Aussagen. :)
Wenn Du Dir vom (ich kenn nun das Datum nicht genau) 15.4.04 0:45 Beispielsweise den Timestamp geben lässt wird diese Differenz vom Jahre 197x sonstwas bis 1:00 (je nach Systemeinstellung) Winterzeit ausgegeben. Gegebenfalls in Sekunden.
Stimmt nicht ganz.
Ausgangspunkt für den Unix-Timestamp ist der 1.1.1970, 0:00. Soweit richtig. Da man aber erkannt hat, das es auf der Welt sowas wie Zeitzonen gibt, die die Zeitberechnung komplizierter machen, ist die ganz präsize Zeitangabe eben "1.1.1970, 0:00 UTC". Also Greenwich-Zeit.
Merke: In der Zeitzone UTC gibt es keine Sommerzeit. Und beim Unix-Timestamp, der auf diesem fixen Zeitpunkt basiert, kommt jede Sekunde eine Sekunde dazu, ohne irgendwelche Sprünge. Kein Unix-Timestamp existiert irgendwie doppelt oder ergibt zwei verschiedene Zeitpunkte aufgrund von Sommerzeitumstellung.
Die Berechnung eines Unix-Timestamp, basierend auf der lokalen Zeit, bezieht logischerweise die lokale _Zeitzone_ mit ein. Deshalb ist es vollkommen egal, ob sich die lokale Zeitzone ändert - diese Änderung fließt automatisch mit in die Berechnung ein.
Deshalb wird bei der Zeitumstellung von MEZ zu MESZ diese Stunde Differenz automatisch berücksichtigt.
Um 02:00 wird die Uhrzeit auf Sommerzeit umgestellt.
Dann wird aus 02:00 03:00. Damit liefert dir der timestamp entsprechende Zahl. Die differenz sind dann 2 Stunden.
Probiere es bitte selbst aus:
<?php
$mk = mktime (01,10,00, 3,28,2004);
echo "<br>Time: $mk<br>";
echo "UTC: ".gmdate("M d Y H:i:s",$mk)."<br>";
echo "local: ".date("M d Y H:i:s",$mk)."<br>";
$gk = gmmktime(01,10,00, 3,28,2004);
echo "<br>Time: $gk<br>";
echo "UTC: ".gmdate("M d Y H:i:s",$gk)."<br>";
echo "local: ".date("M d Y H:i:s",$gk)."<br>";
?>
Zuerst wird ein Unix-Timestamp, basierend auf der lokalen Zeitzone (bei mir: MEZ) generiert für den 28.3.2004, 01:00:00 Uhr. Da kommt bei mir 1080432600 raus.
Dieser Timestamp wird dann einmal als UTC und als lokale Zeitzone wiedergegeben:
UTC: Mar 28 2004 00:10:00
local: Mar 28 2004 01:10:00
Logisch: Wenn es bei und 1:10 Uhr ist, ist es bei uns 1:10 Uhr, und in London/Greenwich ist es erst 0:10 Uhr.
Dann wird der Unix-Timestamp basierend auf der UTC-Zone für 1:10 Uhr desselben Tages gebildet. Ergibt bei mir (und auch bei dir (sollte zumindest)) 1080436200.
Bemerke, dass dieser Zeitstempel genau 3600 größer ist, als der erste Zeitstempel. Logisch: Der erste Zeitstempel war 0:10 UTC, dieser ist 1:10 UTC, also eine Stunde (oder 3600 Sekunden) später.
Die Rückverwandlung in lesbare Zeit ergibt:
UTC: Mar 28 2004 01:10:00
local: Mar 28 2004 03:10:00
Wie man sieht: Die lokale Zeitzone hat zu diesem Zeitpunkt bereits Sommerzeit, die Differenz ist also jetzt zwei Stunden im Vergleich zu UTC. Weil: Wenn es 1:10 UTC ist, wäre es bei MEZ 2:10. Da um 2:00 MEZ aber die Sommerzeit beginnt (Uhren eine Stunde vorstellen), ist es um 2:10 MEZ bereits 3:10 MESZ.
An jedem anderen Tag außer dem 28.3.2004 würden die Differenzen zwischen lokal und UTC bei beiden Beispielen identisch sein.
-> Muss aber zugeben, ich weiss nicht genau, ob nun jedes Unix so doof ist, oder ob manches Unix tatsächlich in der lage ist vernünftige Werte zu liefern.
Unix ist schon sehr lange in der Lage, vernünftige Werte zu liefern - im Gegensatz zu Windows. Wenn obiges Programm also nicht das macht, was ich beschrieben habe, dann war vielleicht Windows im Spiel.
Für Unix wird empfohlen, dass die Systemuhr auf UTC läuft. Außerdem ist die Zeitzone konfiguriert. Aus diesen beiden Informationen kann man jederzeit die lokale Zeit berechnen. Und es gibt auch keine Probleme mit dem Erstellungs- und Änderungsdatum von Dateien, wenn diese auf UTC basierend abgelegt sind. Das läßt sich in einem Schritt auf die lokale Zeit umrechnen und ausgeben.
Windows läßt die Systemuhr auf lokaler Zeit laufen, und speichert Änderungsdaten von Dateien basierend auf lokaler Zeitzone. Das ist insofern schlecht, weil man eben beim Zurückstellen der Sommerzeit zweimal den Zeitraum von 2 bis 3 Uhr auf der lokalen Uhr hat. Wie soll man das umrechnen in eine andere Zeitzone?
In diesem Fall warst Du aber von 01:00 - 03:00 Online
theoretisch 2 Stunden laut Deiner Berechung. In Wirklichkeit warst Du aber 1 Stunde online. Bei mder Telekom bin ich mir nicht sicher, aber ein anständiges Unternehmen würde da auch nicht mehr als 2 Stunde berechnen.
Ok, rechnen wir das mal mit PHP nach. Am 28.3.2004 wird um 2 Uhr die Uhr auf 3 Uhr vorgestellt. Wenn ich also von 1:00 Uhr bis 3:01 Uhr (nur um sicherzugehen) online wäre, dann wären das basierend auf Zahlen 2:01 Stunden, basierend auf echter Zeit aber nur 1:01 Stunden.
<?php
$mk1 = mktime (01,00,00, 3,28,2004);
$mk2 = mktime (03,01,00, 3,28,2004);
echo "<br>Time1: $mk1<br>";
echo "local: ".date("M d Y H:i:s",$mk1)."<br>";
echo "<br>Time2: $mk2<br>";
echo "local: ".date("M d Y H:i:s",$mk2)."<br>";
$diff = $mk2-$mk1;
echo "diff: $diff";
?>
Ergibt:
Time1: 1080432000
local: Mar 28 2004 01:00:00
Time2: 1080435660
local: Mar 28 2004 03:01:00
diff: 3660
3660 Sekunden sind genau 1 Stunde und 1 Minute. Voila! Nichts anderes hätte eine parallel mitlaufende Stoppuhr gezählt - die ja auch nur Sekunden aufaddiert.
Oder reden wir immer noch Meilenweit aneinanderer vorbei?
Du verstehst den Ansatz des Artikels nicht bzw. vermischst ihn mit einem anderen Thema, welches damit nicht das geringste zu tun hat - außer dass es bei beidem um Sekunden geht. Das ist das Problem.
- Sven Rautenberg
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)