Ich persönlich schreibe übrigens nie date(), sondern meistens strftime("%H:%i", locatime(time())) - vielleich geht das ja besser?
Also mit Verlaub, das ist doch nun Humbug hoch drei. time() und localtime() sind zwei verschiedene Paar Schuhe. time() gibt den "Unix timestamp" zurück, welcher eine Ganzzahl ist und sich _grundsätzlich_ auf UTC bezieht bezieht. Es gibt keinen Unix timestamp in einer anderen Zeitzone.
localtime() hingegen gibt keine Ganzzahl zurück, sondern ein Feld mit diversen Zeitinformationen (Stunden, Minuten, Sekunden, die Jahre seit 1900 und solche Scherze).
So gesehen finde ich es schon reichlich putzig, daß Deine obige strftime()-Konstruktion mit localtime() überhaupt funktioniert, denn strftime() erwartet eine Ganzzahl und kein Feld.
Nein. Aber dasselbe wie oben erreichst Du mit
date("H:i")
Eben. date() gibt die lokale Zeit zurück, nichts anderes. Der optionale Unix timestamp ist -wie gesagt- immer in UTC, date() berechnet daraus automatisch die lokale Zeit.
An dieser Stelle ist das reichlich bescheuert erklärt, weil eben nicht time() die lokale Zeit leifert, sondern locatime().
Vollkommen falsch, siehe oben.
<?php
echo date("H:i:s")."\n";
echo gmdate("H:i:s");
?>
Ausgabe:
12:36:36
11:36:36Shell:
date
Fri Jul 11 13:37:45 CEST 2003
Diese (shell-) Zeit ist jetzt aber in jedem Fall korrekt, ja? Wenn dem so ist, sollte das System ja zumindest schonmal richtig funktionieren. Was passiert, wenn Du ntpdate aufrufst? Bleibt die Zeit dann richtig oder wird sie wieder verstellt?
Und der passende ZUgriff aus dem Apache access-log:
[11/Jul/2003:12:36:36 +0100]
Hast Du daran gedacht, den Apache nach den Änderungen (insbesondere /etc/localtime) vorsichtshalber neu zu starten? Werden irgendwelche abartigen Startskripte für Apache verwendet? Versuche httpd mal direkt zu starten (apachectl ist ein Skript).
In jedem Fall scheint Dein Problem ja nicht mit PHP zusammenzuhängen, sondern mit dem kompletten Apache-Prozess (läuft PHP bei Dir als Modul, d.h. als Teil des Servers?).
Gruß,
soenk.e