Skip site navigation (1) Skip section navigation (2)

Re: Zeit und Zeitzonen richtig konfigurieren

From: "Johannes Brgmann" <johannes(at)jottbee(dot)org>
To: pgsql-de-allgemein(at)postgresql(dot)org
Cc: andreas+pg(at)gate450(dot)dyndns(dot)org
Subject: Re: Zeit und Zeitzonen richtig konfigurieren
Date: 2006-04-04 07:05:05
Message-ID: 5zodzhes7y.fsf@jottbee.net (view raw or flat)
Thread:
Lists: pgsql-de-allgemein
Hallo Andreas,
hallo Liste,

Andreas Seltenreich <andreas+pg(at)gate450(dot)dyndns(dot)org> writes:

> Ich versuche mal, auf die noch offenen Fragen einzugehen...

erstmal vielen, vielen, herzlichen Dank für Deine Mühe und Deine guten
Antworten! Dieses Problem hat mich sehr geplagt. Dank Dir ist es nun
behoben.

> Johannes Brügmann schrob:
>
>> (a) mehrere Clients populieren eine Tabelle der Datenbank mit Tupeln
>> der Form (timestamptz, id1, id2, id3, data ...). Dabei bilden
>> timestamptz, id1, id2, id3 den Primärschlüssel. (id1, id2, id3) ist
>> ein referenzierter Fremdschlüssel. Jeder dieser Clients hatte bislang
>> (bis zum "rumspielen" an der Konfiguration heute) die
>> Umgebungsvariable PGTZ=CET und erhält Daten aus der Standardeingabe,
>> die allesamt Winterzeit referenzieren. Jeder dieser Clients erhält
>> seine Zeit als Argument z.B. -t '03.04.2006 12:00:00'. Den Wert
>> dieses
>
> D.h., die Stempel sind immer UTC+01, auch im Sommer? 

Ja. 

Ich habe aber die Möglichkeit, das Argument als -t '03.04.2006
12:00:00' oder -t '03.04.2006 12:00:00 +01' usw. anzugeben, sowie die
Umgebungsvariable PGTZ zu setzen.

> In diesem Fall wäre "CET" die falsche Wahl, denn bei der Verwendung
> als Session-Zeitzone bezeichnet "CET" die Zeitzone als Ort, und
> nicht als Offset. PGTZ=CET verhält sich wahrscheinlich fast
> identisch zu PGTZ=Europe/Berlin.
>
> Damit würde '01.01.2006 12:00:00' zu '01.01.2006 12:00:00 UTC+01'
>         und '01.04.2006 12:00:00' zu '01.04.2006 12:00:00 UTC+02'
> ...und dahin ist die Bedeutungstreue.

Jetzt beginne ich zu verstehen. Sehr gut! Danke.

Eine Frage hätte ich dann aber doch noch:
Was passiert bei 

- PGTZ=CET und '01.01.2006 12:00:00 +01' (Postgres speichert
'01.01.2006 10:00:00 UTC', oder?)

- PGTZ=CET und '01.04.2006 12:00:00 +01' (Postgres speichert
'01.04.2006 09:00:00 UTC', oder?)

mit anderen Worten:

Die Umgebungsvariable und die Ergänzung '... +01' sollten also immer
"mutually exclusive" verwendet werden, richtig?

Langer Rede kurzer Sinn: (a) PGTZ=+01 und keine Ergänzung, der Rest
UTC.

Eigentlich wäre eine solche Ergänzung mit einem oder mehreren guten
Beispielen in der Dokumentation eine feine Sache (pro bono, contra
malum ;-). 

>> Arguments (string, libpqxx) verwendet der Client beim Einfügen in die
>> Datenbank.  Die Tabelle enthält mittlerweile Daten mit mehr als
>> 100GB. Im Endstadium schätze ich das Volumen auf 200GB.
>>
>> (b) andere Clients starten zu einem beliebigen Zeitpunkt und setzen
>> ihre Uhr auf localtime abgerundet auf die volle Minute weniger ein
>> paar gewollten Verzögerungsminuten. Aufgabe dieser Clients ist es, die
>> jeweils ihrer Zeit entsprechenden neuesten Daten zu erfragen und
>> korrespondierende Rechenergebnisse zurückzuschreiben. In der
>> Sommerzeit (CEST) wollen sie die Daten mit ihrem Zeitstempel - 1h; in
>> der Winterzeit - 0h. Auch diese Clients haben PGTZ=CET bzw. jetzt
>> PGTZ=+01.
>
> Wozu hier die Unterscheidung der DST?

Stimmt. Ist Quatsch. Kann ich aber auch jetzt erst feststellen,
nachdem ich das Problem verstanden habe (typisches
Verständnis-Bootstrapping-Problem). 

>> Die Systemzeit war bis gestern Europe/Berlin, seit heute
>> UTC.
>
> Was war die Motivation? 

Motivation war "Rumspielen an der Konfiguration mangels hinreichendem
Verständnis". ;-)

> Was ist mit Systemzeit gemeint? Die Zeitzone des Betriebssystems? 

Ja. Zeitzone und aktuelle Zeit des Betriebssystems.

> Letztere hat AFAIK lediglich Auswirkungen auf den Defaultwert der
> Session-Zeitzone, welchen du ja überall zu überschreiben scheinst.

Ok.

> Wenn die Stempel immer in UTC+01 vorliegen, schröbe ein Client (a) mit
> PGTZ='+01' die Korrekte Zeit in die Datanbank.

Danke, genau das brauche ich!

>> Muss ich Daten seit der Umstellung auf CEST mittels UPDATE
>> aktualisieren?
>
> Auf der Platte liegt nur UTC, ein Update einer timestamptz-Spalte
> macht also nur Sinn, wenn man PostgreSQL einmal über die verwendete
> Zeitzone getäuscht hat, und UTC deswegen nicht UTC ist.

Ich habe PostgreSQL seit Beginn der Sommerzeit über die wahre Zeit
getäuscht. Einen ersten UPDATE-Versuch wies PostgreSQL aber zurück mit
der Begründung, dass Fremdschlüssel kollidieren würden. Ich denke, das
liegt wohl an der falschen Reihenfolge. Führt PostgreSQL eigentlich
eine UPDATE-Anfrage auf mehreren Tupeln parallel aus?

>> 2. Welche PGTZ-Einstellung benötigen die Clients aus (b), damit sie
>> die entsprechenden Daten erhalten? Benötigen diese Clients eventuell
>> oder unbedingt eine besondere Zeitstempelkonvertierung?
>
> S.o., das sollte bei korrektem Import in (a) einklich tun.

Ein erster Test bestätigt Deine Theorie :).

Vielen herzlichen Dank nochmals, Andreas.

Freundliche Grüße,
Johannes Brügmann
-- 


In response to

Responses

pgsql-de-allgemein by date

Next:From: Johannes BrgmannDate: 2006-04-04 08:19:55
Subject: Re: Zeit und Zeitzonen richtig konfigurieren
Previous:From: Andreas SeltenreichDate: 2006-04-04 04:14:23
Subject: Re: Zeit und Zeitzonen richtig konfigurieren

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group