$_SERVER - wo steckt die Zeitzone ?

[Kalle_B]

Hallöle,

habe mich (mal wieder) mit den diversen Umgebungsvariablen $_SERVER beschäftigt.

Sprache, Zeichensatz, alles da.

Aber seltsamerweise nicht die Zeitzone. Ist die in einer anderen Angabe versteckt?

Wäre eigentlich nett, den Ladezeitpunkt einer Seite "richtig" anzuzeigen. Wie es geht, habe ich hier gelernt:
gmdate()

Wie wird eigentlich der Ladezeitpunkt der Forum- Seite angezeigt? Immer Berliner Zeit?

Gruß, Kalle

[wahsaga]

hi,

Aber seltsamerweise nicht die Zeitzone. Ist die in einer anderen Angabe versteckt?

Zeitzone von was?

Die des Servers?
date(): Parameter 'O' Unterschied zu GMT in Stunden, Parameter 'T' Zeitzonenname, Parameter 'Z' Zeitzonenoffset in Sekunden.

Die des Clients?
Javascript.

gruß,
wahsaga

[Christian Seiler]

Hallo wahsaga,

Aber seltsamerweise nicht die Zeitzone. Ist die in einer anderen Angabe versteckt?

Zeitzone von was?

Die des Servers?
date(): Parameter 'O' Unterschied zu GMT in Stunden, Parameter 'T' Zeitzonenname, Parameter 'Z' Zeitzonenoffset in Sekunden.

'T' ist nicht der Zeitzonenname, sondern die Abkürzung der Zeitzone, z.B. 'UTC', 'GMT', 'EDT', 'CEST', etc. Allerdings: Die Abkürzungen sind nicht eindeutig, z.B. bezeichnet CET idR. UTC+1, CEST idR. UTC+2, allerdings kann CET auch UTC+2 und CEST auch mal UTC+3 bedeuten. Bei EDT/EST ist es noch interessanter, die bezeichnen nämlich sowohl Zeitzonen in den USA als auch in Australien (und dazwischen sind etwa 12 Stunden Differenz).

Ferner ist es nicht möglich, mittels der Zeitzonen-Abkürzungen die gültigen Umstellungsregeln für Sommer- und Winterzeit zu ermitteln. Denn die Umstellungsregel kann je nach Land variieren, selbst wenn sie die gleichen Abkürzungen und auch den gleichen Offset im Sommer und im Winter haben, d.h. man bekommt aus dem Zeitzonennamen höchstens ein Offset heraus, und das bekommt man auch durch die anderen Parameter 'O' und 'Z', die Abkürzungen sind in meinen Augen im Prinzip komplett unnütz (Deswegen verbietet RFC 822 z.B. Mailprogrammen, alle möglichen Abkürzungen in den Date-Header zu schreiben, es sind nur ganz bestimmte erlaubt, und spätere RFCs schränken das dann noch weiter ein).

Die einzigen wirklich brauchbaren Zeitzonennamen sind die Schlüssel der tz database, in der Form Europe/Berlin, America/New_York, etc. Allerdings: Diese Zeitzonendatenbank wird aktuell nur von vielen UNIX-Betriebsystemen verwendet, nicht jedoch z.B. von Windows. Microsoft hat unter Windows nämlich ein deutlich simpleres System für die Zeitzonen verwendet - z.B. kann nur eine Zeitzonenwechselregel auf einmal gespeichert werden und viele Zeitzonen (z.B. Europe/Berlin und Europe/Brussels) sind zusammengefasst [1]. Und unter UNIX-Betriebsystemen gibt es keinen Standardweg, die Namen der eingestellten Zeitzone herauszubekommen - manchmal steht in /etc/timezone oder /etc/TIMEZONE der Name drin, manchmal ist /etc/localtime keine Kopie, sondern ein symbolischer Link auf die korrekte Zeitzonendatei selbst, wodurch man etwas am Pfad rumextrahieren könnte. Sofern in PHP allerdings open_basedir gesetzt ist, kann man vergessen, irgendwas in /etc rumzusuchen. Ganz eventuell ist übrigens auch mal die TZ-Umgebungsvariable gesetzt, damit könnte man etwas anfangen (allerdings: selbst wenn sie gesetzt ist, könnte da dummerweise auch wieder nur eine Abkürzung drin stehen).

Alles in allem: Es gibt keinen wirklich guten Weg, den _Namen_ der Systemzeitzone herauszubekommen, der _aktuelle_ Offset zu GMT ist jedoch kein Problem. Da der Offset sich jedoch für frühere oder spätere Zeitpunkte ändern kann (Sommer-/Winterzeit), ist es ausschließlich möglich, den Offset der _aktuellen_ Zeit zu bekommen, bei einem anderem Datum fliegt man da gehörig auf die Schnauze.

Die des Clients?
Javascript.

Genauer gesagt http://de.selfhtml.org/javascript/objekte/date.htm#get_timezone_offset@title=getTimezoneOffset() (allerdings ist da das Offset gerade negativ, d.h. bei UTC+1 liefert die Funktion -1 zurück).

Viele Grüße,
Christian

[1] Was auf gut Deutsch heißt: Windows macht es sich da viel zu einfach, die Zeitzonen werden effektiv nicht korrekt abgebildet. Ich frage mich z.B., wie Microsoft das in Israel anstellt, das Regelwerk dort passt nämlich nicht in das Schema, auf das Windows angewiesen ist. Allerdings: Unter Windows ist es per API-Aufruf problemlos möglich, den Windows-Namen der aktuellen Zeitzone zu bekommen - nützt aber in PHP auch nicht wirklich viel (API-Funktionen aufrufen ist nicht wirklich trivial).

[Sven Rautenberg]

Moin!

'T' ist nicht der Zeitzonenname, sondern die Abkürzung der Zeitzone, z.B. 'UTC', 'GMT', 'EDT', 'CEST', etc. Allerdings: Die Abkürzungen sind nicht eindeutig, z.B. bezeichnet CET idR. UTC+1, CEST idR. UTC+2, allerdings kann CET auch UTC+2 und CEST auch mal UTC+3 bedeuten.

Du forderst Widerspruch heraus. :)

CET hielt ich bislang für "Central European Time", und das ist UTC+1.
CEST ist die Sommerzeit (Central Eurpoean Summer Time), dementsprechend UTC+2.

Und diese Definition bleibt fest, egal was die Sommerzeit geschlagen hat, denn bei der Sommerzeit wechselt man "einfach nur" die Zeitzone, um die Uhr umzustellen.

Welche Varianten machen denn aus CET und CEST +2 und +3 Stunden Offset?

- Sven Rautenberg

[Christian Seiler]

Hallo Sven,

'T' ist nicht der Zeitzonenname, sondern die Abkürzung der Zeitzone, z.B. 'UTC', 'GMT', 'EDT', 'CEST', etc. Allerdings: Die Abkürzungen sind nicht eindeutig, z.B. bezeichnet CET idR. UTC+1, CEST idR. UTC+2, allerdings kann CET auch UTC+2 und CEST auch mal UTC+3 bedeuten.

Du forderst Widerspruch heraus. :)

CET hielt ich bislang für "Central European Time", und das ist UTC+1.
CEST ist die Sommerzeit (Central Eurpoean Summer Time), dementsprechend UTC+2.

Und diese Definition bleibt fest, egal was die Sommerzeit geschlagen hat, denn bei der Sommerzeit wechselt man "einfach nur" die Zeitzone, um die Uhr umzustellen.

Welche Varianten machen denn aus CET und CEST +2 und +3 Stunden Offset?

Ich hatte mir vor einiger Zeit mal eine Liste mit doppelt vorkommenden Zeitzonenabkürzungen samt Offsets aus der bereits erwähnten Zeitzonendatenbank erstellen lassen. Dort waren CET und CEST auch vertreten mit +2 und +3. Ich habe jetzt (nach Deinem Posting) mal nachgeschaut, wann +2/+3 aufgetreten ist und folgende Zone gefunden:

Zone Europe/Kaliningrad  1:22:00 -      LMT     1893 Apr
                         1:00   C-Eur   CE%sT   1945
                         2:00   Poland  CE%sT   1946
                         3:00   Russia  MSK/MSD 1991 Mar 31 2:00s
                         2:00   Russia  EE%sT

D.h. zwischen 1945-01-01 und 1945-04-29 sowie zwischen 1945-11-01 und 1945-12-31 war Kaliningrad in der Zeitzone UTC+2 mit Abkürzung CET und zwischen 1945-04-29 und 1945-11-01 in der UTC+3 mit Abkürzung CEST.

Gleiches gilt z.B. auch für die Zeitzonen WET/WEST (+0/+1 vs. +1/+2), dort gibt's nämlich:

Zone Europe/Luxembourg  0:24:36 -       LMT     1904 Jun
                        1:00    Lux     CE%sT   1918 Nov 25
                        0:00    Lux     WE%sT   1929 Oct  6 2:00s
                        0:00    Belgium WE%sT   1940 May 14 3:00
                        1:00    C-Eur   WE%sT   1944 Sep 18 3:00
                        1:00    Belgium CE%sT   1977
                        1:00    EU      CE%sT

Dort ist zwischen 1940 und 1944 die Zeitzone WET/WEST mit Offset +1/+2 statt mit +0/+1.

Kann natürlich sein, dass die Zeitzonendatenbank da falsch ist; wenn Du dieser Ansicht bist, dann kannst Du ja an die dortige Mailingliste schreiben, dass sie das korrigieren.

Viele Grüße,
Christian

[迪拉斯]

Hey,

unter UNIX-Betriebsystemen gibt es keinen Standardweg, die Namen der eingestellten Zeitzone herauszubekommen

hier kann man sich eine Scheibe von DateTime::TimeZone abschneiden, die Experten haben das alles schon ausklamüsert und dokumentiert. http://search.cpan.org/dist/DateTime-TimeZone/lib/DateTime/TimeZone.pm#The_"local"_time_zone

[Christian Seiler]

Hallo,

unter UNIX-Betriebsystemen gibt es keinen Standardweg, die Namen der eingestellten Zeitzone herauszubekommen
hier kann man sich eine Scheibe von DateTime::TimeZone abschneiden, die Experten haben das alles schon ausklamüsert und dokumentiert. http://search.cpan.org/dist/DateTime-TimeZone/lib/DateTime/TimeZone.pm#The_"local"_time_zone

Ja, wenn man das gerne nachprogrammieren will:

| Some systems just copy the relevant file to /etc/localtime instead of making
| a symlink. In this case, we look in /usr/share/zoneinfo for a file that has
| the same size and content as /etc/localtime to determine the local time
| zone.

Ich sage da nur: Autsch...

Viele Grüße,
Christian