/LINUX: Was tun gegen falsche Uhrzeit?

[Andreas Korthaus]

Hallo!

Also man mag es kaum glauben, aber ch beschäftige mich jetzt seit mehreren Stunden mit dem problem dass ich in PHP time() verwende, auf em neuen Server aber time() einen Zeitpunkt zurückgibt, der hier schoin 1 Stunde vorbei ist. D.h. um 22:06 denkt PHP es ist erst 21:06, was zu nicht unerheblichen Problemen führt (if($time_x > $now)...)

OK. Das Problem ist dass der Server eine Falsch Uhrzeit hat, oder, ich bij mir noch nichtmal sicher ob das falsch ist, wenn ich jetzt(22:08) in der shell 'date' ausführe, dann bekomme ich:

Thu Jul 10 21:07:58 BST 2003

und PHP gint entsprechendes mit seiner time() Funktion zurück.
Jetzt habe ich auch schon einiges probiert(ich verwende übrigens eine RedHat 7.3 Minimal-Installation)

nptdate hat die uhr nur um 3 Sekunden korrigiert, die Uhr geht wohl nicht falsch es ist nur entweder die Zeitzone oder Sommerzeit, oder beides... k.A.

Der bishger beste Tipp war ein Link von /etc/localtime auf  /usr/share/zoneinfo/Europa/Berlin

Gut, danach ging die Uhr 2 Stunden falsch ;-)

Dafür diesmal UTC und nicht BST: Thu Jul 10 18:37:24 UTC 2003

Dann gibt es da noch die Datei /etc/sysconfig/clock, darin steht:

ZONE="Europe/Berlin"
UTC=true
ARC=false

darin kann ich munter ändern was ich will, das wirkt sich so überhaupt nicht aus, genau so wie es kein /usr/sbin/timeconfig gibt.

Welche Zeit soll ich jetzt überheupt verstellen? Geht die überhaupt falsch? Seit wann sind solche Sachen unter Linux so kompliziert? Mit einer GUI hätte ich das sowohl unter win als auch unter linux in 10 Sekunden gemacht, jetzt beschäftige ich mich damit schon einige unerfreuliche Stunden.

leicht depressive Grüße
Andreas

[milky]

Hey!

Die Funktion die du verwenden willst, ist bestimmt localtime()
oder auch locatime(time()). Damit bekommst du die passende Uhrzeit
für unsere Zeitzone (MET), so die richtig eingestellt ist.

time() liefert normalerweise die UNIX-/Internet-Standardzeit (UTC)
zurück - aber eigentlich ist das ja kein Problem wenn sich dein
$now oder $time_x auch daran orientieren könnten (weil macht
sich gut, falls doch mal jemand die Zeitzone verstellt, oder
man auf einen Ami-Server wechseln tut).

MsF,
milky

[Andreas Korthaus]

Hi!

Die Funktion die du verwenden willst, ist bestimmt localtime()
oder auch locatime(time()). Damit bekommst du die passende Uhrzeit
für unsere Zeitzone (MET), so die richtig eingestellt ist.

time() liefert normalerweise die UNIX-/Internet-Standardzeit (UTC)
zurück - aber eigentlich ist das ja kein Problem wenn sich dein
$now oder $time_x auch daran orientieren könnten (weil macht
sich gut, falls doch mal jemand die Zeitzone verstellt, oder
man auf einen Ami-Server wechseln tut).

Aber irgendwas stimmt da nicht. Bisher habe ich einen anderen Server verwendt, da ganz nochmal time() verwenden können, was mir die aktuelle MET Zeit ausgegeben hat. Jetzt bin ich mit der komplettn Anwendung auf einen anderen Server umgestiegen - und da ist alles ne Stunde verschoben! Udn das lässt sich nicht mal eben beheben. Und selbst wenn dann bekomme ich vielleicht Probleme mit der DB oder was weiß ich an welcher Stelle. Irgendwas stimmt nicht. Der Server hat ein ganz neu aufgespieltes Linux-System, udn ich kann daran auch alles verändern(root-Rechte), wenn ich denn wüßte was ich wie ändern sollte! Ich habe bei der Installation von Linux halt immer selbst gewählt, welche Zeitzone... aber das wurde automatisch aus dem Netzwerk installiert, ich habe nur SSH-Zugrif bekommen, und jetzt stehe ich da. Ich kann mir auch vorstellen dass es mit Sommer/Winterzeit zu tun hat, aber ich sitze hier und rate.

Grüße
Andreas

[milky]

Hey,

Bisher habe ich einen anderen Server verwendt, da ganz nochmal time()
verwenden können, was mir die aktuelle MET Zeit ausgegeben hat.

Ja, dann lag hier aber die Fehlkonfiguration bei deinem alten Server,
denn time() sollte wirklich immer die UTC-Zeit zurückliefern. Für den
lokalisierten Wert (inclusive aktueller Zeitzone MET) ist localtime()
zuständig.

Wenn ich übrigens auf meiner Linux-Kiste "date" eingebe (shell/Konsole)
erscheint sowas wie:
Ddd Mmm DD HH:MM:SS CEST 2003
(Man beachte CEST - für Central European Standard Time oder so?)

Bei meiner Debian-Installation habe ich übrigens auch als Zeitzone
"Europe/Berlin" einstellen lassen - aber daß muß ja bekanntermaßen
bei SuSE nicht unbedingt auch zum richtigen Ergebnis führen ;)
(sollte übrigens so in "/etc/timezone" eingetragen stehen, und es
gibt bei mir außerdem die ConfigTools "tzconfig", "tzsetup" und
"time-admin" (gnome))

Ich kann mir auch vorstellen dass es mit Sommer/Winterzeit zu tun hat,
aber ich sitze hier und rate.

Daran liegts sicher nicht, darum kümmert sich auch wieder localtime() - und
das unabhängig von der Zeitzone (hat ja eher etwas mit dem Datum zu tun).

Grüße,
milky

[Henryk Plötz]

Moin,

Ja, dann lag hier aber die Fehlkonfiguration bei deinem alten Server,
denn time() sollte wirklich immer die UTC-Zeit zurückliefern.

Jein, laut Doku "current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)". Also keine wirkliche Uhrzeit, sondern nur die Anzahl der Sekunden seit einem bestimmten Zeitpunkt, welcher aber in GMT angegeben ist.

(Man beachte CEST - für Central European Standard Time oder so?)

Fast, s/tandard/ummer/

[Andreas Korthaus]

Hi!

Ja, dann lag hier aber die Fehlkonfiguration bei deinem alten Server,
denn time() sollte wirklich immer die UTC-Zeit zurückliefern.

Also das kann ich mir nicht vorstellen. Es kann doch nicht sein dass alle Leute die nicht in der GMT-Zeitzone wohnen kein date() und time() verwenden können.

Bei meinem Vorherigen Provider ergab date in der Kommandozeile dasselbe wie bei mir jetzt:

Fri Jul 11 09:50:58 CEST 2003

Also ist die Systemzeit dieselbe. Aber wieso Unterscheiden sich jetzt die Rückgabewerte von date() und time() in PHP? Also ich habe in der php.ini keine Einstellung entdeckt, mit der man vielleicht eien Zeitzone einstellen könnte oder sowas. Habe auch den Apachen testweise neu gestartet - bringt nichst. Außerdem ist die Zeit in dessen Logs ebenfalls eine Stunde zurück. Wie kann ich denn jetzt erreichen dass die Programme dieselbe Zeit verwenden wie date? Oder muss ich dazu neu booten?

cat /etc/sysconfig/clock

ZONE="Europe/Berlin"
UTC=true
ARC=false

Jein, laut Doku "current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)". Also keine wirkliche Uhrzeit, sondern nur die Anzahl der Sekunden seit einem bestimmten Zeitpunkt, welcher aber in GMT angegeben ist.

Und eben dass kan ja in die lokale Zeit umgerechnet werden, und das haben all emeien bisherigen Systeme auch gemacht, auch alle selbst installierten Linuxe, aber das habe ich nicht selbst installiert, keine Ahnung was da jezt falsch ist. date in der Shell funkitoniert ja schonmal, jetzt muss ich es nur noich hinbekommen dass sich PHP, Apache... ebenfalls an diese Zeit halten! Weißt Du wie ich das erreichen kann? Die stören sich nämlich nichz die Bohne wenn icj was an /etc/localtime verändere, auch wenn date in der shell dannn eine 10 Stunden falsche Zeit ausgibt, PHP beharrt auf seiner 1 Stunde, also vermutlich GMT. Aber was kannman machen damit date() und time() meine lokale Zeit zurückgeben? Das _muss_ doch irgendwie gehen. Ich habe bisher aber noch nicht herausbekommen wo sich PHP die Zeit herholt.

Grüße
Andreas

[Henryk Plötz]

Moin,

Welche Zeit soll ich jetzt überheupt verstellen? Geht die überhaupt falsch? Seit wann sind solche Sachen unter Linux so kompliziert? Mit einer GUI hätte ich das sowohl unter win als auch unter linux in 10 Sekunden gemacht, jetzt beschäftige ich mich damit schon einige unerfreuliche Stunden.

Unwahrscheinlich. Wenn du nicht weisst wie die Zeitzonen unter Linux funktionieren und wie man das richtig[tm] einstellt, wirst du es auch mit einer GUI nicht hinkriegen. Windows ist sowieso ein schlechtes Beispiel da die Zeit dort defaultmäßig kaputt ist (genau eine Zeitzone, und es verlangt auch noch dass die Echtzeituhr in dieser Zeitzone geführt wird, was zu lustigen Späßen im Zusammenhang mit Sommer- und Winterzeit führt, besonders wenn man mehrere Windowssysteme dual-bootet).

Üblich ist es unter Linux die Systemzeit und die Echtzeituhr in UTC zu führen und dann für jeden User die Umsetzung in seine Lieblingszeitzone zu machen. Dann hat man auch nicht immer so ein Herumgestelle bei Sommer/Winterzeitwechsel.

In live:
henryk@gleam henryk $ ls -l /etc/localtime
lrwxrwxrwx    1 root     root           33 2002-12-28 07:40 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
henryk@gleam henryk $ date
Fre Jul 11 03:27:13 CEST 2003
henryk@gleam henryk $ TZ=EST date
Don Jul 10 20:27:17 EST 2003

Meine normale Zeitzone ist also auf Berlin eingestellt, was dazu führt dass ich momentan defaultmäßig CEST verwende (im Winter dann ohne weiteres zutun CET).

Deine Zeit geht dann wohl nicht falsch (18:00 UTC = 20:00 CEST), du hast bloß die falsche Zeitzone für die Ausgabe gewählt. Und eigentlich hätte sich das nach dem Setzen des korrekten Links für /etc/localtime erledigt haben sollen.

Sicher dass der Link korrekt ist und das Ziel auch existiert? Wenn ich hier meine localtime nämlich kaputt mache, fällt date sofort auf UTC zurück. Oder vielleicht schwirrt bei dir auch noch die Umgebungsvariable TZ rum?

Weiterführend lesen möchtest du vielleicht http://www.linuxsa.org.au/tips/time.html sowie das Clock Mini-HOWTO.

[Andreas Korthaus]

Hi!

Üblich ist es unter Linux die Systemzeit und die Echtzeituhr in UTC zu führen und dann für jeden User die Umsetzung in seine Lieblingszeitzone zu machen. Dann hat man auch nicht immer so ein Herumgestelle bei Sommer/Winterzeitwechsel.

Aber greift denn PHP auf die Systemzeit zu und nicht auf die lokale? Also muss man die Systemzeit auf die Lokale stellen, wenn in PHP standardmäßig die lokale Zeit in date() und time() haben will?
Kann man in PHP nicht die Standardzeitzone verändern? Ich dachte mit setlocale() aber das geht nicht.

Und wenn date z.B. immer GMT ausgibt, dann sag mir mal jemand warum es dann so eine Funktion gibt:

http://www.php.net/manual/de/function.gmdate.php:

Entspricht der date() Funktion, außer dass als Zeitangabe immer Greenwich Mean Time (GMT) zurück gegeben wird. Steht ihr System in Deutschland (GMT + 01:00), wird im Beispiel unten (1. Zeile) "Jan 01 1998 00:00:00" ausgegeben, wogegen die 2. Zeile "Dec 31 1997 23:00:00" zurück gibt.

Beispiel 1. gmdate() Beispiel

<?php
echo date ("M d Y H:i:s", mktime (0,0,0,1,1,1998));
echo gmdate("M d Y H:i:s", mktime (0,0,0,1,1,1998));
?>

Deine Zeit geht dann wohl nicht falsch (18:00 UTC = 20:00 CEST), du hast bloß die falsche Zeitzone für die Ausgabe gewählt. Und eigentlich hätte sich das nach dem Setzen des korrekten Links für /etc/localtime erledigt haben sollen.

Hat sie, ich hab es nochmal probiert und das ging dann...

Sicher dass der Link korrekt ist und das Ziel auch existiert? Wenn ich hier meine localtime nämlich kaputt mache, fällt date sofort auf UTC zurück. Oder vielleicht schwirrt bei dir auch noch die Umgebungsvariable TZ rum?

Wo soll die rumschwirren?

Weiterführend lesen möchtest du vielleicht http://www.linuxsa.org.au/tips/time.html sowie das Clock Mini-HOWTO.

Ja, ich denke auf dem System komme ich jetzt klar, nur weiß ich nicht warum PHP und Apache sich nicht dran halten.

Hast Du ne Idee woran das liegen könnt?

Grüße
Andreas

[milky]

Hey!

Aber greift denn PHP auf die Systemzeit zu und nicht auf die lokale? Also muss man die Systemzeit auf die Lokale stellen, wenn in PHP standardmäßig die lokale Zeit in date() und time() haben will?

Nein, du MUßT in PHP die Funktion locatime() verwenden um die lokale Uhrzeit zu bekommen, time() liefert IMMER die UTC-Sekunden zurück. Du solltest also deine Scripte anpassen, und nicht die TZ-Einstellungen.

Im übrigen sind das keine PHP-Funktionen, sondern Aufrufe in die Systembibliothek.

Und wenn date z.B. immer GMT ausgibt, dann sag mir mal jemand warum es dann so eine Funktion gibt:

Wenn du dir mit locatime() die lokaliserte Zeit holst, kannst du später trotzdem via gmdate() die Zeit in UTC/GTM ausgeben, d.h. die Zeit würde zweimal umgerechnet (GMT->CEST->GMT).

[...] Oder vielleicht schwirrt bei dir auch noch die Umgebungsvariable TZ rum?
Wo soll die rumschwirren?

in der Shell/Konsole einfach "set" eingeben, und schon bekommst du die Liste der Umgebungsvariablen, wo evtl. auch dieses grußelige TZ drin stehen könnte.

MsF,
milky

[Andreas Korthaus]

Hallo!

Nein, du MUßT in PHP die Funktion locatime() verwenden um die lokale Uhrzeit zu bekommen, time() liefert IMMER die UTC-Sekunden zurück. Du solltest also deine Scripte anpassen, und nicht die TZ-Einstellungen.

Also das würde jetzt wirklich alles über den Haufen werfen was ich seit 2 Jahren mit Zeifunktionen mache! Wofür gibt es dann date() und time()?

Im übrigen sind das keine PHP-Funktionen, sondern Aufrufe in die Systembibliothek.

date() und time() sind keine PHP-Funktionen? Natürlich sind sie das: http://de2.php.net/manual/de/ref.datetime.php
"Datums- und Zeit-Funktionen(!)"

Und wenn date z.B. immer GMT ausgibt, dann sag mir mal jemand warum es dann so eine Funktion gibt:

Wenn du dir mit locatime() die lokaliserte Zeit holst, kannst du später trotzdem via gmdate() die Zeit in UTC/GTM ausgeben, d.h. die Zeit würde zweimal umgerechnet (GMT->CEST->GMT).

exakt, und mit date die lokale Zeit!

http://de2.php.net/manual/de/function.date.php
"date() Gibt einen formatierten String anhand eines vorzugebenden Musters zurück. Dabei wird entweder der angegebene Timestamp oder die gegenwärtige lokale Zeit berücksichtigt, wenn kein Timestamp angegegeben wird. Mit anderen Worten ausgedrückt: der Parameter Timestamp ist optional und falls dieser nicht angegeben wird, wird der Wert der Funktion time() angenommen."

Demnach müsste PHPs Date dasselbe zurückgeben wir date in der Shell, aber das tut es nicht. Und  ich weiß beim besten Willen nicht wieso.

Vielleicht liegt es daran dass die Hardwae-Zeit ebenfalls auf meienr lokalen Zeit steht:

/sbin/hwclock --systohc --utc

bringt da gar nichts, die ausgegeben Zeit ist und bleibt die lokale

Fri 11 Jul 2003 12:42:56 PM CEST  0.707042 seconds

in der Shell/Konsole einfach "set" eingeben, und schon bekommst du die Liste der Umgebungsvariablen, wo evtl. auch dieses grußelige TZ drin stehen könnte.

Ne, die steht d nicht, nur:

_=hwclock

Grüße
Andreas

[Andreas Korthaus]

Hi!

Also ich habe es jetzt mal getestet wue Du gesagt hast:

echo date("H:i")."\n\n";
var_dump(localtime(time(),TRUE));

Das ergibt folgendes:

12:00

array(9) {
  ["tm_sec"]=>
  int(18)
  ["tm_min"]=>
  int(0)
  ["tm_hour"]=>
  int(12)
  ["tm_mday"]=>
  int(11)
  ["tm_mon"]=>
  int(6)
  ["tm_year"]=>
  int(103)
  ["tm_wday"]=>
  int(5)
  ["tm_yday"]=>
  int(191)
  ["tm_isdst"]=>
  int(1)
}

Zum Vergleich in der Shell:

date

Fri Jul 11 13:00:09 CEST 2003

Grüße
Andreas

[milky]

Hey!

Also das würde jetzt wirklich alles über den Haufen werfen was ich seit 2 Jahren mit Zeifunktionen mache! Wofür gibt es dann date() und time()?

Ok, meinetwegen, dann verwendet date() eben doch die lokalisierte Zeit  - dann ist es in der PHP-Doku aber relativ ungünstig erklärt, denn localtime() ist die lokalisierte Zeit.

Ich persönlich schreibe übrigens nie date(), sondern meistens strftime("%H:%i", locatime(time())) - vielleich geht das ja besser?

date() und time() sind keine PHP-Funktionen? Natürlich sind sie das: http://de2.php.net/manual/de/ref.datetime.php
"Datums- und Zeit-Funktionen(!)"

Nö, in PHP gibt es diese Funktionen (wrapper), aber unter UNIX/Linux sollten diese Aufrufe normalerweise an die gleichnamigen Systemfuntionen weitergereicht werden. Siehe auch "man 3 time".

http://de2.php.net/manual/de/function.date.php
"date() Gibt einen formatierten String anhand eines vorzugebenden Musters zurück. Dabei wird entweder der angegebene Timestamp oder die gegenwärtige lokale Zeit berücksichtigt, wenn kein Timestamp angegegeben wird. Mit anderen Worten ausgedrückt: der Parameter Timestamp ist optional und falls dieser nicht angegeben wird, wird der Wert der Funktion time() angenommen."

An dieser Stelle ist das reichlich bescheuert erklärt, weil eben nicht time() die lokale Zeit leifert, sondern locatime().

/sbin/hwclock --systohc --utc

Ich denke mit diesem Befehl stellst du deine Mainboard-RTC auf GMT/UTC um (bis zum Herunterfahren, da SuSE dir das wieder überschreibt). Dürfte im laufenden Betrieb auch keine Auswirkungen haben.

Fri 11 Jul 2003 12:42:56 PM CEST  0.707042 seconds

Das sieht doch schonmal ganz zauberhaft aus - an den Systemeinstellungen mußt du jetzt auf jeden Fall erstmal nicht mehr herumdoktern! Völlig in Ordnung, so wie es dort steht :)

milky

[Andreas Korthaus]

Hi!

Ich persönlich schreibe übrigens nie date(), sondern meistens strftime("%H:%i", locatime(time())) - vielleich geht das ja besser?

Nein. Aber dasselbe wie oben erreichst Du mit

date("H:i")

finde ich irgendwie schöner.

http://de2.php.net/manual/de/function.date.php
"date() Gibt einen formatierten String anhand eines vorzugebenden Musters zurück. Dabei wird entweder der angegebene Timestamp oder die gegenwärtige lokale Zeit berücksichtigt, wenn kein Timestamp angegegeben wird. Mit anderen Worten ausgedrückt: der Parameter Timestamp ist optional und falls dieser nicht angegeben wird, wird der Wert der Funktion time() angenommen."

An dieser Stelle ist das reichlich bescheuert erklärt, weil eben nicht time() die lokale Zeit leifert, sondern locatime().

Naja, ich habe localtime() noch nie gebraucht, time(), date() für aktuielle Zeit, oder ggfs. gmtime() oder gmdate() für selbiges in GMT. Nur will es diesmal nicht funkitonieren. Die Zeit von date() in PHP ist auf die Sekunde gleich mit dem date aus der shell, nur eind Stunde Unterschied. Irgendwo muss es eine Konfigurationsmöglichkeit zu geben, die PHP sagt wie es entsprechend die Zeit umrechnen muss. Naja, aber um die Verwirrung noch perfekter zu machen:

<?php
echo date("H:i:s")."\n";
echo gmdate("H:i:s");
?>
Ausgabe:
12:36:36
11:36:36

Shell:

date

Fri Jul 11 13:37:45 CEST 2003

Und der passende ZUgriff aus dem Apache access-log:
[11/Jul/2003:12:36:36 +0100]

Fri 11 Jul 2003 12:42:56 PM CEST  0.707042 seconds

Das sieht doch schonmal ganz zauberhaft aus - an den Systemeinstellungen mußt du jetzt auf jeden Fall erstmal nicht mehr herumdoktern! Völlig in Ordnung, so wie es dort steht :)

Naja, irgendwo ist da der Wurm drin. Wie gesagt, der Apache hat dasselbe Problem, oder nicht(+0100)?

Grüße
Andreas

[milky]

Hi!

Probiere es doch noch mal mit "export TZ=Europe/Berlin", bevor du deinen
Apache startest (so du eine libphp Version verwendest). Das sollte die
Einstellungen richten, egal wo SuSE die Zeitzonen-Daten hinpackt.

Ansonsten solltest du wirklich mal bei http://php.net/ nachfragen, die
müssten es ja schließlich genau wissen...

Grüße,
milky

[Sönke Tesch]

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:36

Shell:

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

[Andreas Korthaus]

Hallo!

Also ich habe ein neues Script probiert:
<?php
echo date("H:i:s T"), "\n";
echo gmdate("H:i:s T"),"\n";
echo exec('date'), "\n";
?>

was ich erwarte is folgendes:

18:20:09 CEST
16:20:09 GMT
Fri Jul 11 18:20:09 CEST 2003

Was ich aber erhalte ist das:

17:20:09 BST
16:20:09 GMT
Fri Jul 11 18:20:09 CEST 2003

Tja, wie kommt denn PHP da drauf dass ich was mit Engländern zu tun habe?(British Summer Timer)
Ich dachtze erst an eien Problem mit DST, aber das glaube ich hier nach nicht mehr. Ich hätte da 3 Theorien:

1. "date" hat nicht immer in de2r Kommandozeile die CEST ausgegeben, da bin ich erst später drauf gekommen, nachdem ich PHP kompiliert und koinfiguriert habe. Ich bin jetz tnicht sicher ob es BST war, aber ich bin sicher dass damals auch die "date" Version der Shell 1 Stunde nachging, also exakt das geliefert hat was date() mit jetzt in PHP bringt. Vielleicht ist es ja so dass PHP beim Kompilieren oder konfigurtieren einmal die Zeitzone ermittelt und dann fest mit irgendwo reinschreibt. Wobei ich das eigentlich nicht glaube, das wäre sehr unflexibel. Zumal PHP als Modul in meinen Apachen statisch kompiliert ist :-(

2. Variante - es gibt irgendwo ein kleines Schräubchen, eine Konfigurationsvariable ob von PHP oder von Linux oder vom Apachen, keine Ahnung. Ich weiß aber überhaupt nicht wo ich danach noch suchen soll.

3. Variante: Die Änderung der Zeitzone muss im System irgendwie bekannt gemacht werden. Ob durch ein Script, durch ein Neustart eines Dämons oder sogar durch neu booten.

H:i:s")."\n";

echo gmdate("H:i:s");
?>
Ausgabe:
12:36:36
11:36:36

Shell:

date

Fri Jul 11 13:37:45 CEST 2003

Diese (shell-) Zeit ist jetzt aber in jedem Fall korrekt, ja?

Definitiv, 100%ig

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?

Um ein paar 0,001-stel.

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?

ja

Werden irgendwelche abartigen Startskripte für Apache verwendet?

apachectl restart

ersuche httpd mal direkt zu starten (apachectl ist ein Skript).

damit habe ich es gemacht

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?).

Wie gesagt, als in den Apachen einkompiliertes Server-Modul.

Grüße
Andreas

[Henryk Plötz]

Moin,

Tja, wie kommt denn PHP da drauf dass ich was mit Engländern zu tun habe?(British Summer Timer)

Tja, irgendwie hast du dein PHP tatsächlich in eine andere Zeitzone manövriert. Schau dir mal die Ausgabe von phpinfo() an, ob da etwas verdächtiges steht.

Also im PHP-Code in datetime.c ist "BST" bzw. "GMT Standard Time" festverdrahtet, aber in Abhängigkeit von einigen Makros. Hast du das Verzeichnis in dem du PHP kompiliert hast noch? Ich habe zwar keine Ahnung wie das funktioniert, aber soweit ich das sehen kann, wird dieses Festverdrahtete benutzt, wenn HAVE_TM_GMTOFF nicht gesetzt ist.
Mach mal
grep ac_cv_struct_tm_gmtoff config.cache
in dem Sourceverzeichnis (nachdem ./configure gelaufen ist) und es sollte dir
ac_cv_struct_tm_gmtoff=${ac_cv_struct_tm_gmtoff=yes}
ausgeben, wenn alles in Ordnung ist.

Disclaimer: Das ist wildes, unqualifiziertes Rumgerate.

[Andreas Korthaus]

Hallo!

Tja, irgendwie hast du dein PHP tatsächlich in eine andere Zeitzone manövriert. Schau dir mal die Ausgabe von phpinfo() an, ob da etwas verdächtiges steht.

phpinfo() - wonach soll ich da suchen?

var_dump(getenv("TZ"));
habe ich probiert, aber das gibt false(?)

Dann habe ich es mal mit

putenv("TZ=Europe/Berlin");

versucht - und siehe da - es geht! Und sogar bei einem 2. aufruf ohne obiges setzen, aber 1 Minute später geht es wieder nicht.

Wenn ich

export TZ=Europe/Berlin

verwende - also in der shell - wie lange ist dessen Lebensdauern? Bliebt das solange der Apache läuft? Wo genau wird hierdurch dei Änderung vorgenommen? Und wie kan nich das dauerhaft erreichen? ODer wirklich nur mit einer neuen Übersetzung?

Also im PHP-Code in datetime.c ist "BST" bzw. "GMT Standard Time" festverdrahtet, aber in Abhängigkeit von einigen Makros. Hast du das Verzeichnis in dem du PHP kompiliert hast noch?

Ja, ich gucke später mal rein. Ich suche dann mal mit cat file | grep BST

Ich habe zwar keine Ahnung wie das funktioniert, aber soweit ich das sehen kann, wird dieses Festverdrahtete benutzt, wenn HAVE_TM_GMTOFF nicht gesetzt ist.

Oh Gott...

Mach mal
grep ac_cv_struct_tm_gmtoff config.cache
in dem Sourceverzeichnis (nachdem ./configure gelaufen ist) und es sollte dir
ac_cv_struct_tm_gmtoff=${ac_cv_struct_tm_gmtoff=yes}

ac_cv_struct_tm_gmtoff=${ac_cv_struct_tm_gmtoff=yes}

ja, sieht gleich aus.

ausgeben, wenn alles in Ordnung ist.

Disclaimer: Das ist wildes, unqualifiziertes Rumgerate.

Besser das als absolut keine Ahnung...

Danke Dir für die Mühe!

Grüße
Andreas

[Henryk Plötz]

Moin,

var_dump(getenv("TZ"));
habe ich probiert, aber das gibt false(?)

Ist also nicht gesetzt.

Dann habe ich es mal mit

putenv("TZ=Europe/Berlin");

versucht - und siehe da - es geht! Und sogar bei einem 2. aufruf ohne obiges setzen, aber 1 Minute später geht es wieder nicht.

Vermutlich hast du dann einen anderen Prozess erwischt.

Wenn ich

export TZ=Europe/Berlin

verwende - also in der shell - wie lange ist dessen Lebensdauern?

Das gilt für alle Programme die danach _von genau dieser_ Shell aus gestartet werden.

Bliebt das solange der Apache läuft?

Ja, wenn du den Apache von der genannten Shell startest. Dann sollte das aber auch im von phpinfo() angezeigten Environment stehen.

Wo genau wird hierdurch dei Änderung vorgenommen? Und wie kan nich das dauerhaft erreichen?

Es gibt dafür systemweite Einstellungen IIRC in /etc/profile (ich sehe da nicht ganz durch wann welche Einstellungen benutzt werden). Am einfachsten und sichersten geht es aber durch das Modifizieren des Startskriptes des Apache. Also in /etc/init.d/apache (oder so ähnlich) die export-Zeile irgendwo oben hinzufügen.

[Andreas Korthaus]

Hi Henryk!

Wenn ich

export TZ=Europe/Berlin

verwende - also in der shell - wie lange ist dessen Lebensdauern?

Das gilt für alle Programme die danach _von genau dieser_ Shell aus gestartet werden.

ah, verstehe!

Bliebt das solange der Apache läuft?

Ja, wenn du den Apache von der genannten Shell startest. Dann sollte das aber auch im von phpinfo() angezeigten Environment stehen.

Tatsächlich...

Wo genau wird hierdurch dei Änderung vorgenommen? Und wie kan nich das dauerhaft erreichen?

Es gibt dafür systemweite Einstellungen IIRC in /etc/profile (ich sehe da nicht ganz durch wann welche Einstellungen benutzt werden). Am einfachsten und sichersten geht es aber durch das Modifizieren des Startskriptes des Apache. Also in /etc/init.d/apache (oder so ähnlich) die export-Zeile irgendwo oben hinzufügen.

Warum nicht im apachectl? Denn darüber starte ich den Apache normalerweise, nur ist das so ne Sache mit /bin/sh, da existiert diese Variable wohl zur Zeit noch nicht, bzw. steht auf dem alten Wert. Meinst Du durch eine Neustart würde /bin/sh das auch mitbekommen?

Oder ich kann es ja einfach auch in das apachectl-Script schreiben, oder?

Auch Dir vielen DAnk für die Hilfe, jetzt funktioniert es zumindest schonmal, wie es jetzt langfristig gutgeht muss ich noch überlegen...

Grüße
Andreas

[Sönke Tesch]

Tja, irgendwie hast du dein PHP tatsächlich in eine andere Zeitzone manövriert. Schau dir mal die Ausgabe von phpinfo() an, ob da etwas verdächtiges steht.

Es kann nicht an PHP liegen, denn Dein Apache liefert ja auch die falsche Zeit in den Protokollen - und der hat mit PHP in der Hinsicht herzlich wenig zu tun.

Nochmal zum Server:

Werden irgendwelche abartigen Startskripte für Apache verwendet?
apachectl restart

Versuche httpd mal direkt zu starten (apachectl ist ein Skript).
damit habe ich es gemacht

Nein, das solltest Du ja gerade nicht :) In apachectl steckt am Anfang in etwa folgendes:

# the path to your httpd binary, including options if necessary
  HTTPD='/usr/apache2/bin/httpd'

Danach werden Umgebungsvariablen mittels envvars gesetzt (ebenfalls ein Shell-Skript).

Wenn ich mich recht entsinne, tickt Deine Shell momentan nur richtig, weil TZ gesetzt ist. Tippe

export -p

ein, dort muß TZ aufgeführt sein. Falls es nicht ist, exportiere TZ mittels selbigem Befehl.
Starte dann Deinen Apachen _direkt_, über den Pfad, der in der apachectl steht. Nach obigem Beispiel wäre das

/usr/apache2/bin/httpd

Nicht vergessen, den Apachen vorher zu stoppen. Prüfe mit "ps -e", es dauert manchmal etwas, bis sich der letzte Prozess verabschiedet hat.

Egal ob es funktioniert oder nicht, Du solltest auf jeden Fall den Rechner nochmal neu starten, damit auch garantiert jeder die Änderung von /etc/localtime mitkriegt. TZ sollte dann nicht mehr nötig sein.

Bin gespannt, was passiert..

Gruß,
  soenk.e

[Andreas Korthaus]

Hi!

Es kann nicht an PHP liegen, denn Dein Apache liefert ja auch die falsche Zeit in den Protokollen - und der hat mit PHP in der Hinsicht herzlich wenig zu tun.

Ja, also liegt es vermutlich an irgendwelchen Umgebungsvariablen. PHP greift nicht direkt auf Linux-Umgebungsvariablen zu sindrn bekomm tdie wenn nur vom Apachen weitergereicht, oder?

Nochmal zum Server:

Werden irgendwelche abartigen Startskripte für Apache verwendet? apachectl restart

Versuche httpd mal direkt zu starten (apachectl ist ein Skript). damit habe ich es gemacht

Nein, das solltest Du ja gerade nicht :)

OK, so könnte man es auch verstehen ;-)

In apachectl steckt am Anfang in etwa folgendes:

# the path to your httpd binary, including options if necessary   HTTPD='/usr/apache2/bin/httpd'

Danach werden Umgebungsvariablen mittels envvars gesetzt (ebenfalls ein Shell-Skript).

Wo denn? envvars kommt im ganzen apachectl Script nicht vor

Wenn ich mich recht entsinne, tickt Deine Shell momentan nur richtig, weil TZ gesetzt ist. Tippe

export -p

ein, dort muß TZ aufgeführt sein. Falls es nicht ist, exportiere TZ mittels selbigem Befehl.

TZ="Europe/Berlin"

habe ich da. Hieße das, dass dann alle Programme die ich aus eben dieser Shell starte, diese Umgebungsvariablen übergeben bekommen? Das wiederum hieße dass das Startscript diese Variable möglicherweise überschreibt? Aber wo? Also ich habe da nichts von gefunden.

Aber: Du hast tatsächlich Recht! Wenn ich den Server direkt starte, geht es. Du meine Güte, wer kommt denn bitte auf sowas!

;-)

Egal ob es funktioniert oder nicht, Du solltest auf jeden Fall den Rechner nochmal neu starten, damit auch garantiert jeder die Änderung von /etc/localtime mitkriegt. TZ sollte dann nicht mehr nötig sein.

Mh, da warte ich lieber noch bis der Support "in der Nähe" ist ;-)

Werde ich aber tun. Ich hoffe damit ist es erledigt! Kann ich das apachectl Script also nicht mehr verwenden?

Bin gespannt, was passiert..

Ich auch, danke Euch sehr für die großartige Hilfe, habt mir sehr geholfen!

Ach ja, habe mal das apachectl Script gepostet, und ich denke ich habe die Begründung:

#!/bin/sh

es wird also eine anderer Shell verwendet(glaube ich zumindest), die von der Änderung wohl noch nichts mitbekommen hat. Meint ihr das hat sich dann durch einen Neustart erledigt? Oder kann ich über ssh auch Umgebunsgvariablen von /bin/sh setzen?

Also nochmal vielen Dank!

Viele Grüße Andreas

apachectl:

#!/bin/sh

Apache control script designed to allow an easy command line interface

to controlling Apache.  Written by Marc Slemko, 1997/08/23

The exit codes returned are:

#       0 - operation completed successfully #       1 - #       2 - usage error #       3 - httpd could not be started #       4 - httpd could not be stopped #       5 - httpd could not be started during a restart #       6 - httpd could not be restarted during a restart #       7 - httpd could not be restarted during a graceful restart #       8 - configuration syntax error

When multiple arguments are given, only the error from the last

one is reported.  Run "apachectl help" for usage info

|||||||||||||||||||| START CONFIGURATION SECTION  ||||||||||||||||||||

--------------------                              --------------------

the path to your PID file

PIDFILE=/usr/local/apache/logs/httpd.pid

the path to your httpd binary, including options if necessary

HTTPD=/usr/local/apache/bin/httpd

a command that outputs a formatted text version of the HTML at the

url given on the command line.  Designed for lynx, however other

programs may work.

LYNX="lynx -dump"

the URL to your server's mod_status status page.  If you do not

have one, then status and fullstatus will not work.

STATUSURL="http://localhost/server-status"

--------------------                              --------------------

||||||||||||||||||||   END CONFIGURATION SECTION  ||||||||||||||||||||

ERROR=0 ARGV="$@" if [ "x$ARGV" = "x" ] ; then     ARGS="help" fi

for ARG in $@ $ARGS do     # check for pidfile     if [ -f $PIDFILE ] ; then         PID=cat $PIDFILE         if [ "x$PID" != "x" ] && kill -0 $PID 2>/dev/null ; then             STATUS="httpd (pid $PID) running"             RUNNING=1         else             STATUS="httpd (pid $PID?) not running"             RUNNING=0         fi     else         STATUS="httpd (no pid file) not running"         RUNNING=0     fi

case $ARG in     start)         if [ $RUNNING -eq 1 ]; then             echo "$0 $ARG: httpd (pid $PID) already running"             continue         fi         if $HTTPD ; then             echo "$0 $ARG: httpd started"         else             echo "$0 $ARG: httpd could not be started"             ERROR=3         fi         ;;     stop)         if [ $RUNNING -eq 0 ]; then             echo "$0 $ARG: $STATUS"             continue         fi         if kill $PID ; then             echo "$0 $ARG: httpd stopped"         else             echo "$0 $ARG: httpd could not be stopped"             ERROR=4         fi         ;;     restart)         if [ $RUNNING -eq 0 ]; then             echo "$0 $ARG: httpd not running, trying to start"             if $HTTPD ; then                 echo "$0 $ARG: httpd started"             else                 echo "$0 $ARG: httpd could not be started"                 ERROR=5             fi         else             if $HTTPD -t >/dev/null 2>&1; then                 if kill -HUP $PID ; then                     echo "$0 $ARG: httpd restarted"                 else                     echo "$0 $ARG: httpd could not be restarted"                     ERROR=6                 fi             else                 echo "$0 $ARG: configuration broken, ignoring restart"                 echo "$0 $ARG: (run 'apachectl configtest' for details)"                 ERROR=6             fi         fi         ;;     graceful)         if [ $RUNNING -eq 0 ]; then             echo "$0 $ARG: httpd not running, trying to start"             if $HTTPD ; then                 echo "$0 $ARG: httpd started"             else                 echo "$0 $ARG: httpd could not be started"                 ERROR=5             fi         else             if $HTTPD -t >/dev/null 2>&1; then                 if kill -USR1 $PID ; then                     echo "$0 $ARG: httpd gracefully restarted"                 else                     echo "$0 $ARG: httpd could not be restarted"                     ERROR=7                 fi             else                 echo "$0 $ARG: configuration broken, ignoring restart"                 echo "$0 $ARG: (run 'apachectl configtest' for details)"                 ERROR=7             fi         fi         ;;     status)         $LYNX $STATUSURL | awk ' /process$/ { print; exit } { print } '         ;;     fullstatus)         $LYNX $STATUSURL         ;;     configtest)         if $HTTPD -t; then             :         else             ERROR=8         fi         ;;     *)         echo "usage: $0 (start|stop|restart|fullstatus|status|graceful|configtes t|help)"         cat <<EOF

start      - start httpd stop       - stop httpd restart    - restart httpd if running by sending a SIGHUP or start if              not running fullstatus - dump a full status screen; requires lynx and mod_status enabled status     - dump a short status screen; requires lynx and mod_status enabled graceful   - do a graceful restart by sending a SIGUSR1 or start if not running configtest - do a configuration syntax test help       - this screen

EOF         ERROR=2     ;;

esac

done

exit $ERROR

[Sönke Tesch]

Ja, also liegt es vermutlich an irgendwelchen Umgebungsvariablen. PHP greift nicht direkt auf Linux-Umgebungsvariablen zu sindrn bekomm tdie wenn nur vom Apachen weitergereicht, oder?

Jein. Da Du PHP als Modul benutzt, _ist_ PHP der Apache, der Webserver setzt sich zusammen aus dem Apache-Code und dem PHP-Code. Es gibt aus Programmausführungssicht also keinen Unterschied zwischen den beiden Komponenten.
Hendryks Ausführungen nach greift PHP ziemlich direkt auf Systemfunktionen zu, die ihrerseits dann die Umgebungsvariablen verarbeiten. Dort kann ein Fehler nicht stecken, die einzige Möglichkeit wäre weiter vorne in der Kette, nämlich daß der Apache seine Umgebungsvariablen selbst ändert (wovon dann natürlich auch PHP betroffen wäre). Das passiert aber sicher nicht, denn es macht einfach keinen Sinn, TZ zu löschen.

BTW: TZ erscheint, wenn es gesetzt ist, in phpinfo() unter "Environment" ziemlich am Ende der Seite.

In apachectl steckt am Anfang in etwa folgendes:

Danach werden Umgebungsvariablen mittels envvars gesetzt (ebenfalls ein Shell-Skript).
Wo denn? envvars kommt im ganzen apachectl Script nicht vor

Oh, dann ist das neu beim Apache 2.

export -p

TZ="Europe/Berlin"

habe ich da. Hieße das, dass dann alle Programme die ich aus eben dieser Shell starte, diese Umgebungsvariablen übergeben bekommen?

Ja, d.h. der Apache, sofern er von dort gestartet wird, sollte diese Variable übergeben bekommen.

Aber: Du hast tatsächlich Recht! Wenn ich den Server direkt starte, geht es. Du meine Güte, wer kommt denn bitte auf sowas!

;-)

Ich, egal wie krank es sein mag ;)

Werde ich aber tun. Ich hoffe damit ist es erledigt! Kann ich das apachectl Script also nicht mehr verwenden?

Ach ja, habe mal das apachectl Script gepostet, und ich denke ich habe die Begründung:

#!/bin/sh

es wird also eine anderer Shell verwendet(glaube ich zumindest),

Jein, /bin/sh zeigt in der Regel auf die Standardshell des Systems, was wiederum meistens /bin/bash ist. Allerdings versucht bash sich zumindest teilweise wie sh zu verhalten, wenn als als sh aufgerufen wird. Vielleicht hilft es deshalb, wenn Du dort statt sh bash einträgst - ich glaube es allerdings nicht, denn bei mir funktioniert's mit /bin/sh.

Ansonsten ist es mir ebenfalls schleierhaft, warum das Skript bzw. Apache im Skript TZ nicht mit auf den Weg bekommt. Vielleicht setzt Du einfach mal ein

set

an den Anfang des Skripts und probierst das mal mit /bin/sh und /bin/bash. Es sollten alle Umgebungsvariablen erscheinen. Vielleicht gibt's da ja tatsächlich einen Unterschied. Falls ja, prüfe vielleicht mal die Einstellungen Deiner Shell, die diversen Konfigurationsdateien sind in der Anleitung beschrieben (man bash).

Gruß,
  soenk.e

[Andreas Korthaus]

Hi!

Jein. Da Du PHP als Modul benutzt, _ist_ PHP der Apache, der Webserver setzt sich zusammen aus dem Apache-Code und dem PHP-Code. Es gibt aus Programmausführungssicht also keinen Unterschied zwischen den beiden Komponenten.
Hendryks Ausführungen nach greift PHP ziemlich direkt auf Systemfunktionen zu, die ihrerseits dann die Umgebungsvariablen verarbeiten.

Aber die Umgebungsvarieablen erhält der Apache beim Starten und PHP über die SAPI, oder?

Dort kann ein Fehler nicht stecken, die einzige Möglichkeit wäre weiter vorne in der Kette, nämlich daß der Apache seine Umgebungsvariablen selbst ändert (wovon dann natürlich auch PHP betroffen wäre).

Ich glaube nicht dass er die ändert(wüßte zumindest nicht wie oder wo), ich glaube dass die Shell die das  apachectl Script ausführt noch nichts von der Änderung der Zeitzone mitbekommen hat - warum auch immer, denn diese habe ich ja erst kürzlich verändert.

Das passiert aber sicher nicht, denn es macht einfach keinen Sinn, TZ zu löschen.

Es ist ja BST, genau die Zone die vorher standard war. Also vermute ich wie gesagt, dass da einer noch nichts von der Änderung mitbekommen hat. Wobei /bin/sh ja kein Dämonprozess ist und sich so bei jedem Laden die Umgebungsvariablen neu holen sollte. Vielleicht  hat es auch damit zu tun dass ich nur mit SSH drauf zugreife? Also auch damit apachectl starte, und auch da /etc/localtime verändert habe...?

BTW: TZ erscheint, wenn es gesetzt ist, in phpinfo() unter "Environment" ziemlich am Ende der Seite.

Ja, wenn die steht da wenn ich sie manuell im Script setze.

export -p

TZ="Europe/Berlin"

habe ich da. Hieße das, dass dann alle Programme die ich aus eben dieser Shell starte, diese Umgebungsvariablen übergeben bekommen?

Ja, d.h. der Apache, sofern er von dort gestartet wird, sollte diese Variable übergeben bekommen.

Sollte ich dann am besten in die erste Zeile des apachectl Scriptes folgendes einfügen:

export TZ='Europe/Berlin'

Wobei ich das bisher noch gar nicht ausgeführt habe, nur hat das, wenn ich das richtig verstanden habe eh nur auswirkungen auf den aktuellen Prozess in dem ich das ausführe, oder?

Außerdem ist das ja nicht die Lösung sondern eher ein schlechter Workaround.

Ich vermute fast dass es durch einen Neustart erledigt werde, ich werde den Server morgen irgendwann in einer ruhigen Minute mal starten.

Aber: Du hast tatsächlich Recht! Wenn ich den Server direkt starte, geht es. Du meine Güte, wer kommt denn bitte auf sowas!

;-)

Ich, egal wie krank es sein mag ;)

Hat mir jedenfalls sehr geholfen. Ist wirklich erschrecken wie lange man sich mit solch doofen Problemen rumschlagen darf... aber hat ja auch was gute, hab ewieder ne Menge über Linux dazu gelernt, und mir das erste mal nähere Gedanken über die Zeitfunktionen von PHP gemacht...

Ach ja, habe mal das apachectl Script gepostet, und ich denke ich habe die Begründung:

#!/bin/sh

es wird also eine anderer Shell verwendet(glaube ich zumindest),

Jein, /bin/sh zeigt in der Regel auf die Standardshell des Systems, was wiederum meistens /bin/bash ist.

Ich dachte immer das sei eine eigene?

ls -l /bin/sh

lrwxrwxrwx    1 root     root            4 Jul  9 13:50 /bin/sh -> bash

Hast wohl schon wieder Recht...

Allerdings versucht bash sich zumindest teilweise wie sh zu verhalten, wenn als als sh aufgerufen wird. Vielleicht hilft es deshalb, wenn Du dort statt sh bash einträgst - ich glaube es allerdings nicht, denn bei mir funktioniert's mit /bin/sh.

Die Sache ist ja, dass durch #/bin/sh eine neue (Unter-)Shell geöffnet wird. Woher bezieht die denn die Umgebungsvariablen? Aus der aktuellen Shell? ODr holft die die irgendwo her? Ich könnte es mir erklären wenn es einen Dämon gäbe der evtl. von den Änderungen nichts mitbekommen hat, aber das wäre mir zumindest neu(ist also gut möglich ;-))

Ansonsten ist es mir ebenfalls schleierhaft, warum das Skript bzw. Apache im Skript TZ nicht mit auf den Weg bekommt. Vielleicht setzt Du einfach mal ein

set

an den Anfang des Skripts und probierst das mal mit /bin/sh und /bin/bash. Es sollten alle Umgebungsvariablen erscheinen. Vielleicht gibt's da ja tatsächlich einen Unterschied. Falls ja, prüfe vielleicht mal die Einstellungen Deiner Shell, die diversen Konfigurationsdateien sind in der Anleitung beschrieben (man bash).

Mache ich mal, aber vorher probiere ich es mit einem Neustart. Kann doch eigentlich nicht sein dass man die Zeitzone für alle möglichen Anwendungen extra setzen muss, die Änderungen des Lionks /etc/localtime sollte doch eigentlich ausreichen, oder?

Nochmals vielen Dank! Ich hatte schon gedacht ich sei verrückt und würde mein Lebtag date() und time() falsch verwenden ;-)

Grüße
Andreas

[Henryk Plötz]

Moin,

Aber die Umgebungsvarieablen erhält der Apache beim Starten und PHP über die SAPI, oder?

PHP und Apache sind in dem Fall der selbe Prozess. Da ein Prozess üblicherweise nur eine Umgebung hat, hat PHP also die selbe Umgebung wie der Apache. (Naja, könnte noch sein dass PHP da noch was dazwischen schiebt und eine Umgebung emuliert, aber da glaube ich nicht dran.)

Ich glaube nicht dass er die ändert(wüßte zumindest nicht wie oder wo), ich glaube dass die Shell die das  apachectl Script ausführt noch nichts von der Änderung der Zeitzone mitbekommen hat - warum auch immer, denn diese habe ich ja erst kürzlich verändert.

Ich denke es war eher gemeint, dass das apachectl-Skript, bzw. das Skript dass du zum Starten des Apache benutzt seine Zeitzone selber irgendwann ändert oder aus den Tiefen der Konfiguration (was auch immer bei dir das Äquivalent zu rc.conf ist) hervorholt bevor es den Apachen startet.

Sollte ich dann am besten in die erste Zeile des apachectl Scriptes folgendes einfügen:

export TZ='Europe/Berlin'

Zweite Zeile, in der ersten steht schon #!/bin/sh  ;-) Aber ja, das wäre eine mögliche Lösung.

Wobei ich das bisher noch gar nicht ausgeführt habe, nur hat das, wenn ich das richtig verstanden habe eh nur auswirkungen auf den aktuellen Prozess in dem ich das ausführe, oder?

Ja, bloß dass das so jedesmal beim Apachestart ausgeführt würde und daher immer auf den Apache wirkt.

Außerdem ist das ja nicht die Lösung sondern eher ein schlechter Workaround.

ACK

Die Sache ist ja, dass durch #/bin/sh eine neue (Unter-)Shell geöffnet wird. Woher bezieht die denn die Umgebungsvariablen? Aus der aktuellen Shell?

Ja, ein neuer Prozess bezieht seine Umgebung eigentlich immer von dem Prozess von dem geforkt wurde. (Und ausser init entstehen alle Prozesse durch forken eines anderen Prozesses.)

Mache ich mal, aber vorher probiere ich es mit einem Neustart. Kann doch eigentlich nicht sein dass man die Zeitzone für alle möglichen Anwendungen extra setzen muss, die Änderungen des Lionks /etc/localtime sollte doch eigentlich ausreichen, oder?

Ja, ausser natürlich ein Prozess bzw. sein Startskript doktert selber an der Zeitzone rum, wie oben vermutet.

[Henryk Plötz]

Moin,

Naja, ich habe localtime() noch nie gebraucht, time(), date() für aktuielle Zeit, oder ggfs. gmtime() oder gmdate() für selbiges in GMT.

Also ich habe nochmal im Quellcode nachgeschaut. time() ist recht einfach implementiert:

/* {{{ proto int time(void)
   Return current UNIX timestamp */
PHP_FUNCTION(time)
{
        RETURN_LONG((long)time(NULL));
}
/* }}} */

Die Funktion kann also gar nichts anderes machen als den aktuellen Wert von time() (also der Systemfunktion) zurückzugeben. Das ist laut man 2 time:
| time  returns the time since the Epoch (00:00:00 UTC, January 1, 1970),
|       measured in seconds.

Das date() von PHP hingegen ruft php_date() auf und setzt den zweiten Parameter (gm) auf 0, was dazu führt dass dieses sich seine Zeit von php_localtime()_r holt. gmdate() von PHP ruft auch php_date() auf, setzt den zweiten Parameter aber auf 1, woraufhin sich dieses seine Zeit von php_gmtime_r holt. Das sind jeweils nur Wrapper um die Systemfunktionen localtime_r() und gmtime_r(), die das tun was ihr Name andeutet.

Die Doku scheint bei der Beschreibung der beiden Funktionen also mal korrekt zu sein.

[Andreas Korthaus]

Hallo!

Das date() von PHP hingegen ruft php_date() auf und setzt den zweiten Parameter (gm) auf 0, was dazu führt dass dieses sich seine Zeit von php_localtime()_r holt.

OK. Dann frage ich mich aber, was denn da nicht funktioniert. Wo genau fragt denn php_localtime()_r seine Zeit ab und wo macht das das "date" aus der Shell? Wie kommt PHP bitte da drauf dass ich BST als localtime habe, zumal /etc/localtime was vollkommen anderes sagt? Holt sich PHP die Zeit/Zeitzone nicht zur Laufzeit? Wenn doch - woher? Reicht die Einstellung von /etc/localtime nicht? Oder wir das an anderer Stelle konfiguriert? Hat aber nichts damit zu tun das PHP in den httpd einkompiliert ist, oder?
Oder kann es damit zu tun haben, dass ich zum Zeitpunkt der Übersetzzng der PHP und Apache-Sourcen noch BST-Zeit hatte, das erst später umgestellt habe, als ich es gemerkt hatte. Aber PHP wurde nicht mit umgestellt. Kann es sein dass die Zeitzone bei ./configure oder make... ermittelt und fest in den Code geschrieben wurde?

Und wenn ich mir das Log-Datum des Apachen angucke:

[11/Jul/2003:12:36:36 +0100]

Müsste da nicht +0200 stehen, bezohen auf GMT? Also hat der wohl dasselbe Problem. Bekommt PHP evtl. die lokale Zeitzone vom Apachen wenn es als Apache-Modul läuft? Dann ist das Problem vielleicht beim Apachen zu suchen, aber den habe ich ja nach der Änderung der /etc/localtime mehrmals neu gestartet. Vielleicht hat der die Zone fest im Quellcode stehen?

Also entweder steht das irgendwo im Quelltext oder es gibt da eine Konfigurationsmöglichkeit die ich nicht finde.

Viele Grüße
Andreas

[Henryk Plötz]

Moin,

Ok, meinetwegen, dann verwendet date() eben doch die lokalisierte Zeit  - dann ist es in der PHP-Doku aber relativ ungünstig erklärt, denn localtime() ist die lokalisierte Zeit.

Du musst zwischen *date() und *time() unterscheiden!

Lokalisiert: date(), localtime()
Nichtlokalisiert: gmdate(), time()

(Laut Doku)

[Henryk Plötz]

Moin,

Aber greift denn PHP auf die Systemzeit zu und nicht auf die lokale? Also muss man die Systemzeit auf die Lokale stellen, wenn in PHP standardmäßig die lokale Zeit in date() und time() haben will?

Dann üben wir mal Doku zu lesen:
time() - "current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)"
date() - "using the given integer timestamp or the current local time if no timestamp is given"

Kann man in PHP nicht die Standardzeitzone verändern? Ich dachte mit setlocale() aber das geht nicht.

setlocale() - "specifying the category of the functions affected by the locale setting: LC_ALL for all of the below [...]  LC_TIME for date and time formatting with strftime()"

[Andreas Korthaus]

Hi!

Also, ich suche jetzt ca. 10 Dtunden nach einer Lösung hierfür, das kann ja irgendwie nicht war sein!

Hat jemand ne Idee wo man so eine Frage vielleicht mal stellen könnte?

Alos bisher habe ich es bei

• slinuxforen.de
• redhat Mailingliste
• de.comp.lang.installation
• Selfforum
• Support des Providers

probiert, aber bis jetzt habe ich es nicht klären können.

Das System ist eine Standard-Installation(Redhat 7.3 Minimal-Installation), und den Apachen + PHP(in Apache einkompiliertes Modul) habe ich ganz normal aus den Sourcen kompiliert, wieso habe ich so ein Problem was anscheinend niemand kennt? Naja, vermutlich bin ich nicht der erste mit dem Problem, nur ich weiß wirklich nicht mehr wo ich noch suchen/fragen kann.

Hat jemand von Euch einen Tipp? Oder vielleicht einen Tipp wie ich weiter vorgehen soll, wo der Fehler noch zu finden sein könnte?

Könnte es mit der Hardware zusammenhängen(Bios-Zeit), oder müsste ich irgendeinen Dienst neu starten oder irgendein Script ausführen um meine Änderung irgendwie bekannt zu machen? Oder gibt es noch eine andere Konfigurations-datei oder eine andere Systemfunktion die PHP verwendet? Oder den Rechner neu booten? Neustart des Apachen bringt jedenfalls nichts.

Viele Grüße
Andreas