Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2006-12-06 10:05:51

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

[de-de] (Sommer-) Zeitproblem

Ich habe Probleme mit den Zeiteinstllungen und konnte im Forum dazu nichts finden:

Es geht um diese Webseite:
Evangelisch in Neuhausen-Nymphenburg
darin den Kalender als Kalender und als Liste

Meine Installation ist korrekt auf deutsche Zeit GMT+1 eingestellt.
Dazu war ebenfalls korrekt Sommerzeit (DST) eingestellt.

Ich habe darin einen Kalender laufen, der Veranstaltungen über die Zeitmarke des Artikels einordnet (d.h. auch zukünftige) und mit time=“future” bzw. “any” arbeitet.
Soweit lief bisher alles bestens – unter der Voraussetzung Sommerzeit.

Nun mein Problem: Nach dem manuellen Rückstellen auf Winterzeit (erfolgte erst jetzt)
werden alle Artikel um eine Stunde zurückgesetzt. Und so natürlich auch die angezeigte Zeit in den Veranstaltungshinweisen!

Wenn ich es dagegen auf Sommerzeit stehen lasse, werden die Veranstaltungen bei der Einstellung time=“future” natürlich eine Stunde zu früh ausgeblendet bzw. die Tagesumstellung im Kalender erfolgt bereits um 23 Uhr.

Was tun?

  • ich hätte natürlich gerne korrekte Zeitstempel, d.h. die Serverzeit sollte korrekt eingestellt werden können.
  • d.h. die Änderung müsste bei den Artikeln erfolgen (bzw. das Rückgängigmachen der automatischen Änderung)
  • das Problem: Die Artikel/Zeiteinträge werden nicht von mir, sondern von mehreren Autoren vorgenommen. Ich kann auch schlecht feststellen, wann das geschehen ist (da es ja future-Zeiteinträge sind, ich müsste also die “zuletzt geändert”-Zeit auswerten, und auch die ist nicht aussagekräftig, wenn jemand mehrfach geändert hat.)
  • Wenn ich jetzt die Zeit richtig einstelle, könnte/müsste ich alle Artikelzeiten entsprechend manuell korrigieren – und dabei darauf achten, wann die Artikeleinträge erstellt wurden, d.h. unter welchen Zeitbedingungen sie eingegeben wurden. Sonst ändere ich einen Artikel, der evtl. schon unter korrekter Zeit eingegeben wurde. Richtig verzwickt dabei: Es betrifft ja auch alle alten Einträge. Die aber sind in einem Archiv (bzw. rückläufigen Kalender) und sollen noch einsehbar und auch von der Zeit her korrekt sein. Sie alle zu ändern, erscheint mir als Quatsch.
  • wenn ich das jetzt recht verstehe, geht es darum, die eingetragene Artikel-Zeit zu fixieren, d.h. sie nicht mit einer Änderung der Zeiteinstellungen in den Preferences neu zu berechnen. Was also als “11:00:00” eingetragen ist, soll also um “11:00:00” bleiben, egal, welche Zeitzone und ob Sommerzeit eingestellt ist.

Müsste man dazu den txp-code selbst verändern?
Ginge das mit einem Plugin?

Vielleicht hat jemand damit Erfahrung oder kann mir sagen, wo ich etwas entsprechend einstellen kann.

Vielen Dank für Tipps!

Last edited by saccade (2006-12-06 10:09:05)

Offline

#2 2006-12-08 11:55:48

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Bin inzwischen von Sencer auf den entsprechenden Thread verwiesen worden.
Dort habe ich einen Vorschlag bzw. Überlegungen gepostet.
Hier auch nochmal auf Deutsch, weil sich da vielleicht manches besser klären lässt.
(Sorry, dieses Deutsch geht stellenweise holprig an meinem Englisch entlang. Bitte einfach nachfragen, wenn’s zu dubios ist ;-) )

Behandlung der “Zeit” in Textpattern

Anmerkung: Leider ist der folgende Beitrag lange und auf den ersten Blick kompliziert.
Aber ich habe versucht, die Problematik mit den verschiedenen Zeiteinstallungen und der Behandlung der Zeit in Textpattern gründlich und konsequent durchzudenken.

A Was ist “Zeit”?
Es gibt nich die eine Zeit für alle(s)

Wir müssen verschiedene Zeiten bzw. Zeitformen unterscheiden:

A-0 (diese eher philosophische Vorrede kann man überspringen. Sie ist ein Rahmen zum Verständnis des folgenden.)
Es gibt die Zeit an sich
Sie beginnt und endet irgendwo, Anfang und Ende können wir nicht (be-)greifen.
Dass heißt für uns gibt es keinen greifbaren Anfang und kein greifbares Ende und damit auch kein wirkliches Maß oder eine Einheit.
In unserem Abschnitt der Zeit können wir lediglich über Relationen sprechen: Wir können exakt sagen: “Die geschah vor jenem” oder “Dies ist bezogen auf diesen Bezugspunkt zu dieser Zeit” (Bezugspunkte: z.B. Mitternacht 0 Uhr, Christi Geburt, usw.)
Das Problem ist, dass es unterschiedliche Bezugspunkte gibt. Wir können uns auf den Tag-Nacht-Zyklus beziehen oder auf ein bestimmtes Ereignis. Wir könnten auch unterschiedliche Einheiten verwenden.
Um besser mit der Zeit umgehen zu können, setzen wir einen Punkt (willkürlich!) absolut. Siehe A-1.

A-1
Es gibt eine absolute Zeit.
“Absolut* hier im Sinne von “losgelöst”.
Dies ist eine Hilfskonstruktion, um die Zeit an sich handhabbar zu machen.
Die “absolute Zeit” wird in einer einzigen Einheit von einem (willkürlich gesetzten, aber allgemein anerkannten) Bezugspunkt – sagen wir z.B. Jahresbeginn 1970 – aus gezählt.
Jedes Ereignis (z.B. ein post) hat seinen eindeutigen Platz auf dieser Skala.
In Bezug auf diese Skala bekommt das Ereignis so seinen eindeutigen, unveränderbaren Zeitstempel, der unabhängig davon ist, wo man gerade ist und welche “Zeit” dort gerade gilt.
Die absolute Zeit ist strukturell konsistent, durchgängig, man könnte sagen ewig, es gibt darin keine Unterschiede, Brüche oder Doppelungen.
Das Zählsystem, der Code der Zeit kann regelmäßige Zyklen widerspiegeln, muss es aber nicht (man könnte in Erdumdrehungen = Tagen, Sonnwenden etc. zählen). Es könnte genausogut eine völlig andere Zeiteinheit gewählt werden (da z.B. auch die Planetenbewegungen ein klein wenig unregelmäßig ist, wird heute die Atomzeit mit einer genaueren Einheit gerechnet und von Zeit zu Zeit – Achtung! – die nur hier absolute Zeit um eine Sekunde angepasst).
Die einzige Einschränkung ist: Die absolute Zeit darf keine Lücken oder Doppelungen aufweisen [idealerweise sollte das so sein, GMT wird jedenfalls so betrachtet, die Schaltsekunde vernachlässigen wir hier].
Die absolute Zeit völlig logisch angeordnet und besteht aus einer notwendigen Reihenfolge (von Zahlen).

Ihr Vorteil: Zeitangaben sind vergleichbar und sehr exakt. Sie können leicht geordnet und berechnet werden.
Ihr Nachteil: Niemand kann sich vorstellen, was eine Angabe, wie “Sekunde 433294521 seit 1970” bedeutet. Auch nicht, ob das irgendwo früh oder spät, Tag oder Nacht ist.

A-2
Es gibt eine konventionelle Zeit.
“konventionell” hier im Sinne von Übereinkunft.
Diese Zeit ist, was eine Gruppe von Menschen als “ihre” Zeit definieren und worauf sie sich beziehen. Planungen, Treffen, Zeitvergleiche werden auf die gegenwärtig gültige, vereinbarte Zeitzählung bezogen.
Diese konventionelle Zeit wird auch unterschiedlich gezählt: 12stündig, 24stündig, nach Stunden, Minuten usw. und vor allem auch mit verschiedenen Kalendarien.

Immerhin gibt es für die Tageszeit kaum unterschiedliche Systeme (zumindest ist mir keines bekannt).

Aber es gibt eine Sonderregelung, die hier wichtig ist: Sommer- und Winterzeit (DST).

Die konventionelle Zeit ist kontextabhängig bzw. kontextbedingt. Sie gilt in bestimmten Gegenden (Zeitzonen) und in bestimmten Zeiträumen (z.B. zur Sommerzeit) mit unterschiedlichen Regeln.
Diese Gegenden und Zeiträume sind im Prinzip zufällig bzw. willkürlich (oder eben vereinbart/konventionell). Sie sind nicht logisch und notwendig (klar, ein bisschen logisch, aber eben nicht ausschließlich. Logisch wäre z.B. dass Frankreich dieselbe Zeit hätte wie England).
Die konventionelle Zeit muss nicht einmal periodisch sein: Die Sommerzeit z.B. wurde irgendwann eingeführt, dann ihr Geltungszeitraum verändert, möglicherweise wird sie wieder aufgegeben).
Das heißt: Die konventionelle Zeit ist nicht konsistent, nicht durchgehend, sondern hat Brüche und Änderungen. Sommer-/Winterzeit usw. (z.B. gibt es beim Wechsel zur Sommerzeit die Stunde zwischen 2 und 3 gar nicht, dafür beim Wechsel zur Winterzeit gleich zweimal.

Ihr Vorteil: Die konventionelle Zeit vermittelt ein fast überall verständliches Bild davon wann (in Bezug auf die Umgebung) etwas geschehen ist: zu Tag- oder Nachtzeit, früh oder spät, im Sommer oder im Winter usw.
Ihr Nachteil: Die Zeiten sind nur dann leicht miteinander vergleichbar, wenn sie demselben Kontext angehören. Sobald sie sich über sehr verschiedene Kontexte erstrecken (z.B. Zeitzonen), lösen die Unterschiede und Brüche/Besonderheiten verwirrung aus – wenn nicht jemand ein mathematisches Gefühl dafür hat und zugleich alle geltenden Regeln schnell ineinander umrechnen kann.

A-3
Die konventionelle Zeit wird von weiteren Faktoren bestimmt: z.B. als lokale Zeit
Aus praktischen Gründen beginnt die konventionelle Zeit normalerweise jeden Tag morgens oder nachts mit der Neuzählung, so dass überall auf der Welt z.B. der Sonnenaufgang annähernd z.B. um 6 Uhr statttfindet und eben nicht um 23 Uhr. Das ist der Sinn der Zeitzonen und führte zu ihrer Einrichtung (oder anders: die Leute haben eben von Sonnenaufgang oder Mitternacht aus gerechnet).
Da die konventionelle Zeit dem Bezug der Leute vor Ort dient, wird sie eigentlich immer als Ortszeit angegeben, wobei örtlich eben auch noch zusätzliche Gepflogenheiten wie Sommerzeit usw. die Unterschiede zwischen verschiedenen Orten verstärken.

A-4
Die Ortszeit bezieht sich auf den Ort.
Soweit so gut, aber was ist im Web der “Ort”?
Da sich die Kommunikation sogar über Zeitzonen hinweg verteilt, bezihen sich die Gesprächspartner jeweils für sich auf verschiedene konventionelle Zeiten.
Wenn man dann eine Zeit kommuniziert, muss klar werden, welche Zeitkonvention (=Zeitzone, DST, Zeitregel) gemeint ist.
Normalerweise wird dazu einfach der Ort der Website, die lokale Zeit der Website (normalerweise ist das die lokale Zeit ihres Besitzers) verwendet.
[damit meine ich nicht die Serverzeit. Die kann ja wieder unterschiedlich sein, weil die Website daraus die passende angezeigte Zeit errechnet.]

A-5
Es gibt aber eben auch die Orte, an denen die Benutzer gerade sind, also die lokale Zeit des Benutzers (bzw. jedes einzelnen Benutzers)

A-6
So entspricht einem Ereignis mit einer einzelnen absoluten Zeit eine ganze Menge an verschiedenen Zeiten für dieses Ereignis.

the same in english

Last edited by saccade (2006-12-09 08:12:53)

Offline

#3 2006-12-08 17:55:18

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

B Nun zum Umgang mit der Zeit in Textpattern

Die obengenannten Zeitformen sind in der bisherigen Diskussion alle aufgetaucht. Einige Verwirrung beim Reden über “Zeit” kann daher rühren, dass Begriffe mit unterschiedlicher Bedeutung (wenn einer einen Aspekt z.B. mit einschließt, der andere diesen Aspekt aber gerade ausschlißt oder anders füllt) oder aus unterschiedlichem Blickwinkel gesehen werden.

Ich versuche, die obengenannten Typen entsprechend auf das txp-Zeitmanagement anzuwenden:

B-1
Im Moment wird in txp in der Datenbank bei den einzelnen Artikeln/Kommentaren nur die absolute Zeit gespeichert (siehe A-1).
Diese wird korrekterweise nicht geändert und sollte es auch nicht.
Dieser Zeitstempel garantiert, dass wir genau feststellen können, in welcher Reihenfolge Artikel oder Kommentare eingegangen sind (oder wie sie eben nacheinander angeordnet sein sollen, wenn der Zeitstempel manuell gesetzt wird).
Dies im Grunde völlig losgelöst davon, wo und zu welcher lokal gültigen Zeit ein Artikel/Kommentar gepostet wurde (denn diese Angaben werden nicht mitgespeichert).
Man hat so eine allgemeine, einheitliche und für alle gültige Basis.
So weit ist das ja richtg und sollte nicht geändert werden.

B-2
Momentan wird auch die konventionelle Zeit verwendet [siehe A-2 – allerdings nicht vollständig, siehe im folgenden].
Diese Zeitangabe basiert im Moment auf dem vorgestellten Ort der Website [A-4]. D.h. der “Normalzeit”, die für die Webseite gilt.
Diese Zeitregel wird durch die Einstellung der Zeitzone und der DST/Sommerzeit vorgenommen, die also die aktuell gültige Zeitregel bilden und die absolute Zeit aus der Datenbank (angegeben in GMT) in die auf der Website gültige Zeit umrechnen (indem Zeitzone und ggf. Sommerzeit hinzugerechnet werden).

Notabene: Diese Zeitregel in Übereinstimmung mit der Zeit “draußen in der richtigen Welt” zu halten, ist Aufgabe des admin. Also z.B. im rechten Moment die Sommerzeiteinstellung vorzunehmen. Mehr dazu später.

Hieraus resultiert nun aber das Hauptproblem:

txp berücksichtigt nur einen Aspekt der konventionellen Zeit: Es kenntn nur die gerade im Moment gültige Zeit-Regel. (Dies ist eine 1:alle- oder 1:x-Relation).
txp berücksichtigt dagegen nicht einen wichtigen anderen Aspekt der konventionellen Zeit:
Nämlich den Gesichtspunkt der Kontextualität.
(Kontextuell bedeutet hier: eingebettet in die wirkliche Zeit draußen, die mal so und mal so gilt und historisch, geschichtlich ist. Ein Artikel müsste demnach die Zeit behalten, die er damals auch wirklich hatte – und nicht eine zwar rechnerisch korrekte Zeit, die aber einem anderen Bezugssystem/Kontext angehört. Der Kontext ist: Die damals gültige Zeitzone/DST-Einstellung, nicht die gegenwärtig gültige.)
txp hat leider nicht die geringste Erinnerung daran, welche Zeitregel zum Zeitpunkt des Zeitstempels gültig war. lso welche Zeitzone damals eingestellt war, und ob Sommerzeit galt oder nicht.
(Die gültige Zeitregel ist eine 1:1-Relation).
Das heißt: Hier erfolgt doch eine Änderung der Zeit in dem Moment, in dem die Zeiteinstellungen geändert werden. Zwar werden die Ziffern des GMT-Stempels nicht angerührt, aber das originale Bezugssystem wird verändert.
Die originale Zeitinformation = absolute Zeit in GMT + kontextuelle (bis dahin webseitenweite) Einstellung von Zeitzone und Sommerzeit, geht verloren.
Sie war nur durch die Kombination des absoluten Zeitstempels in der Datenbank und der Zeiteinstellung im Admin-Bereich korrekt vorhanden. Wenn sich eines ändert, ändert sich die kontextuelle konventionelle Zeit bzw. geht die originale Zeit verloren.

Durch Anwendung einer neuen Zeitregel (konventionelle Zeit, z.B. Winterzeit) auf Zeitstempel, die ihren Ursprung in einer anderen Zeitregel (z.B. Sommerzeit) haben, wird aber eine falsche Information generiert – und dies geschieht noch dazu jedesmal aufs neue, wenn sich etwas ändert.

Bezogen auf Sommerzeit heißt das: Ich ändere mit jeder Umstellung jeden älteren Artikel. Will ich ihn unter den Bedingungen der neuen Zeit korrigieren, muss ich das von Hand tun. Und zwar jedesmal für alle alten Artikel aufs neue, d.h. jedesmal werden es mehr.

Wie bereits gesagt:
Wenn ich zum Beispiel im Sommer sage “Johannes beendete seine Sommerschule 2006 um 15 Uhr”, dann ist das immer 15 Uhr (=GMT13 Uhr+1+1/Sommerzeit). Denn der Bezugsrahmenist immer die damals gültige Zeit. Und dabei ist es egal, ob im Hintergrund Sommer- oder Winterzeit steht. Es geht nur um die aktuell gültige Zeit.
Unter den momentanen Bedingungen in txp würde aber aus diesem Satz einen anderen machen, wenn ich ihn im Winter erneut ausspreche/lese: Es hiesse dann: “Johannes beendete seine Sommerschule 2006 um 14 Uhr” (=GMT13 Uhr+1+0/Winterzeit),
Im nächsten Sommer hieße es dann wieder 15 Uhr und dann im Winter wieder 14 Uhr.
Niemand würde so mit “der” Zeit umgehen, auch wenn es basierend auf der absoluten Zeit und unter Berücksichtigung der aktuellen Regel RICHTIG ist.
Kurz gesagt: Wir beziehen uns auf Zeit immer historisch und nicht nur anhand der gerade gültigen Regeln. Wir halten instinktiv an den damals geltenden Regeln fest und beziehen diese in unsere Erinnerung/Überlegungen mit ein.
txp tut das aber leider nicht.

Szenarien, wo eine historisch fixierte bzw. kontextuell gültige Zeit sehr wichtig ist:
  • Live-Kommentare, z.B. bei Sportereignissen
  • Kommentare bzw. Nachrichten, die z.B. Wahlergebnisse kommentieren, darüber berichten. Man stelle sich vor eine erste Hochrechnung würde wundersamerweise später mit einer Zeitangabe versehen sein, die eine Stunde vor Schließen der Wahlllokale liegt. Oder die Erklärung eines Kandidaten, man habe die Wahl gewonnen bei knappem Wahlergebnis. Hier würde eine später falsch generierte Zeitangabe, die eine Stunde früher liegt, ein stark verändertes Bild geben.
    So unrealistisch ist dieses Szenario nicht. Soviel ich weiß, nutzen ja z.B. die Demokraten in Amerika t.T. textpattern als Grundlage (hab ich jedenfalls irgendwo im Forum gelesen, kann es gerade nicht mit Link belegen).
    Das wäre dann nicht nur für die Beteiligten sondern auch für textpattern peinlich.
  • Berichte von einer Konferenz oder pressetechnisch, presserechtliche Veröffentlichungen benötigen auch oft eine sichere und kontextuelle Zeitbasis.

B-3
An diesem Punkt braucht txp meiner Meinung nach ganz klar eine Verbesserung: Die konventionelle Zeit (mindestens die jeweils im damaligen Moment gültigen Zeitregeln) zum Zeitpunkt der Erstellung des Zeitstempels müssen mitgespeichert werden.
Dies muss eigentlich auf Basis des einzelnen Artikels/Kommentars erfolgen.

(jedenfalls meiner Meinung nach, weil es mehr Möglichkeiten eröffnet und am sichersten ist. Es gibt evtl. eine Möglichkeit ohne das auszukommen, dann braucht es aber eine umfangreiche Datenbank mit allen vorhandenen Zeitregeln auf aller Welt. s.u.)

Für eine optimale Funktion brauchen wir unbedingt beide Teile der Zeitinformation:
  • Die absolute Zeit wird für die richtige Sortierung der Artikel in Bezug aufeinander benötigt. Anders gesagt: Für die Beziehung zwischen Artikeln. Und sie wird als einfachste und praktischste Basis für die Berechnung aller Zeitangaben benötigt. Natürlich könnte man auch überall nur die konventionelle Zeit zusammen mit ihrer Kennung/Regel speichern. Auch diese lassen sich ineinander umrechnen und vergleichen, aber dazu braucht man eine vollständige, lückenlose Tabelle aller vorhandenen Zeitregeln mit allen Daten, Ausnahmen und Brüchen.
  • Die natürlich korrekt eingestellte _konventionelle Zeit (oder mindestens für jeden Artikel die vollständige zum Zeitpunkt des Zeitstempels gültige Regel, egal ob vergangen, aktuell oder in Zukunft zu veröffentlichen) wird benötigt, um den Artikel korrekt in seinem gültigen Kontext (“draußen, richtige Welt”) zu veröffentlichen bzw. auszublenden und in seiner “posted”-information auch die konventionell “richtige” Zeit anzuzeigen. Vor allem brauchen wir das, wenn es darum geht, dass Artikel zu bestimmten Zeitpunkten in der wirklichen Welt veröffentlicht werden bzw. wieder verschwinden, also in Kalendern oder Veranstaltungslisten.

Meine Folgerung: Beide Informationen müssen in der Datenbank bei einem Artikel/Kommentar gespeichert werden.
Es gibt keinen Weg darum herum [unter bestimmten Voraussetzungen doch, s.u.].
Weil beide Teile einen wichtigen Teil der Gesamtinformation enthalten.

Überlegung: Wir sollten natürlich auch darüber nachdenken, ob eine der beiden Infos auch aus der anderen errechnet werden könnte:
1. Natürlich benötigen wir dafür in jedem Fall eine vollständige Tabelle aller Zeitregeln, die möglicherweise gültig sein könnten, und zwar für vergangene wie für zukünftige Zeiten.
Mit Bezug auf die großartige Nutzergemeide von txp sollte das keien Schwierigkeit sein :-)
2. Also: Kann eine Zeit aus der anderen errechnet werden?
Zuerst: absolute Zeit -> Konventionelle Zeit?
Nein. Man kann die konventionelle Zeit nicht aus der absoluten errechnen, wenn man gar nicht (mehr) weiß, welche Regel damals in Geltung war. (Ausnahme s.u.)
Es gibt nur einen Weg, wie aus der absoluten Zeit die konventionelle errechnet werden kann. Wenn eine korrekte Zusatzinformation vorhanden ist, welche Zeiteistellung der Autor verwendet hat.
Und umgekehrt: konventionelle Zeit -> absolute Zeit
Dies ist einfach, solange die tatsächliche Zeit in Ziffern und die gültige Zeitregel angegeben ist.

Wie sollten die absolute und die konventionelle Zeit gespeichert werden?

  • B-3.0 Natürlich sollte wie bisher die absolute Zeit in GMT gespeichert werden, z.B. (GMT) 12:00

zusätzlich dann:

  • B-3.1 Mindestens die aktuelle konventionelle Zeit in Ziffern. z.B. dann hier in Deutschland im Sommer: 14:00
  • B-3.2 Oder der Zeitunterschied zwischen absoluter und konventioneller Zeit. Zum Besipiel: +2:00

(B-3.1 und B-3.2 hängen direkt zusammen und können voneinander errechnet werden. Bei beiden aber geht auch ein Teil Information verloren: Ob man nun in Zeitzone X+3 oder in X+2+1DST ist, ist nämlich numerisch gleich und ist daher ununterscheidbar. Wenn dies von Interesse sein sollte, z.B. für eine Zeitzonenangabe, dann ist folgendes besser:

  • B-3.3 Besser: Detaillierte Info über die verwendete Zeitzone nd DST-Regel, die gerade in Kraft sind. So kann man sich besser vorstellen, wo das ist. Die aktuelle Zeit in Ziffern kann dann aus der absoluten Zeit mit der Regeltabelle errechnet werden. Zum Beispiel: GMT+1+1DST oder identisch MEZ+1DST oder ebenfalls identisch MESZ
  • B-3.4 Noch besser: Voll bestimmt: Die reale Zeit in Ziffern plus die genaue Zeitzone/DST-Einstellung. Zum Beispiel: 14:00 MESZ

Edit: Wenn es darum geht, redundante Information zu vermeiden und die Infos wirklich auf die essentiellen Bestandteile herunterzubrechen, dann ist natürlich B-3.3 ausreichend. Vorausgesetzt natürlich, man hat eine durchdefinierte, eindeutige Zeitregel. Die reale konventionelle Zeit kann dann aus der absoluten GMT-Zeit plus Anweendung der Regeln errechnet werden. Dies ist eine eindeutige Angabe.

EDIT: Wenn man kein zusätzliches Feld einführen möchte
Hier also die oben öfters erwähnte Minimallösung:
Wenn kein zusätzliches Feld in die Artikeleinträge der Datenbank soll, dann muss mindestens eine Tabelle mit allen vorhandenen Zeitregeln implementiert werden, die angibt wo wann welche Regel galt bzw. gelten wird – inklusice der DST/Sommerzeiten.
Aus der absoluten Zeit und diesen Angaben kann nämlich für eine definierte Zeitzone die richtige Zeit errechnet werden.
Es müsste dann außerdem beim Präsentiereneines Artikels die Zeit entsprechend der kontextuellen Regeln zur Zeit des Zeitstempels errechnet werden.
Das geht dann zwar nur über eine extern (ggü. Artikeln) in den Einstellungen für die gesamte Website definierte Zeitzone – aber immerhin!
Der Fehler, dass eine momentan gültige DST-Einstellung unterschiedlos auf alle Artikel aller Zeiten angewendet wird, wäre dann weg.
In diesem Fall behalten wir allerdings die Beschränkung, dass txp nur eine einzige aktuelle Zeitzone kennt.
Aber damit lebt man bisher ja nicht so schlecht.
Man kann nur leider dann auch nicht parallel in zwei oder mehreren Zeitzonen arbeiten (siehe B-5.2)
Die würde also den Fehler korrigieren und ist besser als das bisherige. Ich selbst halte das allerdings für noch zu wenig und hätte sehr viel lieber eine volle Lösung. Für mich liegt eine Stärke von textpattern in seiner internationalen Ausrichtung. Die kann noch besser ausgespielt werden, wenn man das Management verschiedener Zeitzonen hinzunimmt. Die folgenden Überlegungen gehen daher davon aus, dass tatsächlich die anzuwendende Zeitregel zusammen mit jedem einzelnen Artikel gespeichert wird. Als selbstverständlicher Teil des Zeitstempels.

B-4
Worauf sollen nun die verschiedenen Zeitangaben angewendet werden? Was ist ihre Funktion?
Die absolute Zeit (A-1) ist nötig für das richtige zeitliche Anordnen der Artikel untereinander. Es bestimmt die Reihenfolge, in der die Artikel angezeigt werden, wenn sie zeitlich geordnet sind. Durch die absolute Zeit wird die historische Reihenfolge der Artikel beibehalten, in der sie entstanden sind (oder eben veröffentlicht werden sollen, wenn es sich um time=future-stamps handelt)

Die (kontextuelle) konventionelle Zeit (A-2) wird verwendet, um zu definieren, wann ein Artikel veröffentlicht wird oder eben verschwindet (z.B. wenn ich jetzt eine Veranstaltung im nächsten Sommer poste und 15 Uhr MESZ angebe). Und vor allem dazu, die richtige Zeitinformation z.B. posted-Zeit anzugeben. Die konventionelle Zeit betrifft nämlich die Relation der Artikel zu ihrer Umgebung in der wirklichen Welt/Zeit der Benutzer.

the same in english

Last edited by saccade (2006-12-09 08:16:29)

Offline

#4 2006-12-08 19:16:23

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

B-5
Nun geht es um die verschiedenen Blickrichtungen auf die konventionelle Zeit.
Folgende Aspekt gibt es:

B-5.1 eine einzige Zeitzone berücksichtigen
Momentan behandelt txp nur eine momentan aktuelle konventionelle Zeit (s.o. A-4) als konventionelle Zeit der Website.
Dies ist die Zeit, die wir im “Verfassen”-Manü des Admin-Bereichs unten sehen. Diese Zeit wird für den automatischen Zeitstempel verwendet, wobei leider ja nur der absolutze Anteil und nicht die momentane Zeitregel gespeichert wird.
Auch eine manuell eingegebene Zeit wird unter Berücksichtigung dieser Einstellung gespeichert (d.h. aus dieser Zeit wird unter Verwendung der momentan eingestellten Regel eine “absolute Zeit” errechnet und diese gespeichert).
Diese Zeit wird zur Präsentation aller Zeiten bei der Ausgabe herangezogen.

Als Benutzer weiß ich doch normalerweise, dass ich in einen Zeitkontext hineinspreche oder -schreibe.
Eina ganz andere Frage ist, ob dies meine momentan aktuelle Zeit ist.
Wenn ich einen Beitrag auf eine amerikanische Seite schreibe, gehe ich normalerweise davon aus, dass dieser Eintrag mit der dortigen Zeit angezeigt wird.
Will ich dann mitteilen, dass es hier spät in der Nacht ist (in Deutschland), kann ich das nicht mit einem Zeitstempel tun, sondern sage es in Worten oder ich saage deutlich, dass es hier so uns so spät ist (als Text).
So würde ich es auch auf einem Flug oderbeim Kreuen mehrerer Zeitzonen tun.

In dieser Hinsicht finde ich eigentlich keine Änderung notwendig. Es könnte ohne weiteres dabei bleben, dass es auf einer txp-Webseite nur diese eine “lokale Webseiten-Zeit” gibt (wobei evtl. Änderungen wie oben dargelegt erhalten bleiben MÜSSEN).

B-5.2 mehrere Zeitzonen berücksichtigen
Ich kann mir allerdings sehr leicht (und schön) eine internationale/multikulturelle Webseite vorstellen, in der die verschiedenen lokalen Zeiten der Benutzer auch sichtbar sind.
Das bedeutet dann allerdings, dass wir eine Möglichkeit benötigen, mit der verschiedene Zeitregeln verwaltet werden können.
Da aus den obengenannten Gründen die Bezugsgröße “Zeitregel” sowieso mitgespeichert werden sollte (ich lasse die Minimallösung hier außer acht), und daher die Information selbst schon in jedem Artikel mitgeführt wird (werden sollte), wäre nur noch eine Möglichkeit zu schaffen, dass ein Benutzer für seinen Artikel oder Kommentar angeben/auswählen kann, auf welche Zeitzone/DST sein Beitrag bezogen werden sollte.
Von einer solchen Ausklappliste z.B. könnte der Benutzer seine lokale Benutzerzeit [A-5] (=Zeitzone plus DST manuell oder automatisch nach Tabelle&Datum) auswählen, die dann beim Darstellen des Beitrags angezeigt werden sollte.
Wenn im Zeitstempel manuell eine zukünftige Zeit eingegeben würde, würde die Regelauswahlliste bestimmen, in welcher Zeitzone diese Zeit erreicht sein muss, damit der Artikel veröffentlicht wird bzw. wieder verschwindet (falls z.B. nur “future”-Artikel angezeigt werden wie bei einer Veranstaltungsankündigung).

Ich träume ein bisschen: Es könnte dann z.B. solgende Liste von Beiträgen geben, die jeweils eine Minute auseinander sind:
“Hi, here is Gregorios” posted GMT 15:33
“Welcome, good morning, my name is John”, posted EDT 8:34
“Hi, good evening, Gregorius and John, my name is Abdel, it’s a wonderful sunset in Teheran now”, posted IRT 17:05
Vorteil: Hier würde eine Vorstellung vermittelt, in welchem Kontext jemand schreibt, zu welcher lokalen Zeit.
Nachteil: Wenn man mit der Zeitverschiebung nicht vertraut ist, weiß man zwar dessen lokale Situation (morgens, abends, zu Arbeitszeiten oder am Feierabend), aber nicht wirklich, wie lange die Beiträge auseinanderliegen (sprich: wie weit auseinander ist EDT 8.34 und IRT 17.05 tatsächlich?).
Lösung: Da sowieso eine Referenzzeit da ist (die absolute), könnte man eine zweite Zeit als Referenz anzeigen, die für alle gleich ist.
Es hängt insgesamt davon ab, was man mit einer Zeitangabe eigentlich mitteilen will.

Eine andere Situation, in der gemischte Zeitzonen für die Zeitangaben wünschenswert sein können:
Man stelle sich beispielsweise eine detsche weltweit arbeitende Kultureinrichtung vor. Diese hat eine deutsche Webseite mit einer großen Menge an Beiträgen. Natürlich werden die mit deutschen Zeiten ausgezeichnet und nach deutscher Zeit veröffentlicht.
Nun gebe es aber eine kleine Dependance in Australien. Diese Dependance arbeitet auch mit der Unternehmensseite auf Deutsch (sagen wir, es ist eine Spracheinrichtung und deren australische Kunden sprächen Deutsch. Diese Dependance möchte aber nun eine Kalender mit Veranstaltungen betreiben.
Das Problem: Muss sie nun ihre Beiträge separat in deutsche Zeit umrechnen und diese Zeiten eingeben, damit sie dann zu entsprechend gewünschter australischer Zeit publiziert bzw. versteckt werden?
Wenn diese Zeiten dann irgendwo angezeigt würden, würden sie doch nur verwirren.
Eine elegante Lösung wäre mit der einstellbaren Zeitregel möglich: “Benutze australische Zeit 15 Uhr” für die Publikation.
Dann könnte z.B. die australische Sektion australische Zeit anzeigen, die deutsche deutsche Zeit. Intern würde korrekt mit Standardzeit gerechnet.

Dies alles wäre natürlich wunderbar und eine schöne Weise wirkliche Internationalisierung zu visualisieren (und dabei die regionalen Unterschiede als guten Kontext einzubeziehen).
Aber ich weiß, dass es auch eine Menge Arbeit wäre, dies zu implementieren.
Andererseits: Die erste Hälfte des Weges müssen wir ja praktisch meiner Meinung nach eh gehen.

B-5.3 einzelne Zeitzone berücksichtigen, aber mögliche Änderungen einkalkulieren
Wenn eine komplette txp-Installation in eine andere Zeitzone umzieht (das wurde hier auch diskutiert). ändert sich ja normalerweise die Lokalzeit der Webseite [A-4].
Beim gegenwärtigen Zeitmanagement, würden damit alle Einträge zeitverschoben und eine “falsche” Zeit tragen.
Das wäre möglicherweise hinnehmbar, wenn es nicht so drauf ankommt, aber sonderbar ist es schon.
Bei großen Unterschieden in der Zeitzone hätte man etwa plötzlich ausschließlich “Mitternachts-/Nachtposter”.

Bisher gibt es keine Möglichkeit, dann die originale Zeit zu erhalten – wenn man nicht die Übereinstimmung mit der neuen lokalen Zeit opfert und einfach mit der alten Zeiteinstellung weitermacht. Oder eben alle alten Beiträge entsprechend ändert.

Mit der von mir vorgeschlagenen Lösung eines neuen Zeitmanagements, bei dem die aktuelle Zeitregel des Zeitstempels mitgespeichert wird, könnte man leicht für alle alten/bestehenden Postings deren originale Zeit und Zeitzone anzeigen lassen. Für die neuen dagegen deren aktuelle gültige Zeit (und Zeitzone). In diesem Fall bräuchte man noch nicht einmal einen Auswahldialog, denn die aktuelle (admin-eingestellte) Zeit würde ja jeweils automatisch mitgespeichert.

Für die korrekte logische Reihenfolge von Artikeln entsteht dabei keinerlei Problem, denn der spekt der absoluten Zeit ist ja ebenfalls erhalten. Die zeitliche Beziehung zwischen den Artikeln ist ja unabhängig von der jeweils verwendeten Zeitzone gespeichert.

the same in english

Last edited by saccade (2006-12-09 08:11:20)

Offline

#5 2006-12-08 20:31:27

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Einige Gedanken zur Handhabung einer Änderung:

Wenn nun also ein zusätzliches Feld für die Zeitregel im Artikeleintrag eingefügt werden soll,
ist natürlich zu fragen, was mit den bereits existierenden Artikeln geschehen soll:

  • Wenn die alten Artikel alle derselben Zeitregel angehören, sollte es einfach sein: allen die gewünschte Zeitregel zuordnen und ggf. die reale Zeit daraus errechnen.
  • Wenn sie gemischte Regeln enthalten (etwa aus Winder- und Sommerzeiten stammen), dann könnte mit einer Tabelle eermittelt werden, welche Zeitregel gegriffen hat.
    Das ist natürlich nur korrekt, wenn sich nicht die Zeitzone zwischenzeitlich auch geändert hat.
  • Wenn sie tatsächlich komplett gemischt sein sollten (eher unwahrscheinlich, weil es das ja nicht gab), dann müsste das Feld für jeden Artikel manuell gefüllt werden.
Evtl. könnte man auch ein zusätzliches Attribut für die article-tags und/oder eine allgemeine Einstellung in den Einstellungen einführen, mit dem festgelegt wird, nach welchem Zeitmodell die Webseite arbeiten soll:
  • mit dem Modell einer konventionellen/kontextuellen (realen) Zeit
  • oder mit einer einzigen Zeitregel für alle. Das würde dann das jetzige Verhalten wieder in Kraft setzen.

DST/Sommerzeit
Oben habe ich einmal die manuelle Einstellung der Sommerzeit in den Einstellungen erwähnt.
Hier eine andere Idee:
Warum erstellen nicht die großartigen Benutzer von Textpattern im Forum eine möglichst komplette Datenbank/Tabelle aller möglichen Zeitzonen und ihrer jeweiligen DST-Regelungen.
Dies für mehrere Jahre rückwärts und vorwärts. Und natürlich kontinuierlicher Pflege, denn manchen Regeln werden ja auch von Zeit zu Zeit geändert – DST ist eine willkürliche Sache.
Diese Tabelle könnte ebenso in txp eingebunden werden wie momentan die Sprachdateien.
Dann würde es in den Einstellungen ausreichen, die entsprechende Zeitzone auszuwählen – und von Zeit zu Zeit die Regeltabelle aktualisieren zu lassen.
Die DST/Sommerzeiteinstellungen könnten dann automatisch von txp angewendet werden.

the same in english

Last edited by saccade (2006-12-09 08:10:42)

Offline

#6 2006-12-10 11:36:10

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Nach einigem weiteren Nachdenken muss ich noch ein paar Punkte nachbessern und klarstellen.
Dabei geht es um das genaue Verhältnis der absoluten Zeit (im Zeitstempel) und der konventionellen Zeit:

B-1 revidiert
Derzeit wird in txp die absolute Zeit [A-1] im Zeitstempel verwendet.
Der Zeitstempel gewährleistet, dass wir die logische Reihenfolge der Artikel einhalten können. Die absolute Zeit sichert Konsistenz, egal wo und zu welcher Ortszeit ein Benutzer einen Artikel/Kommentar erstellt hat.
Durch den Zeitstempel wird jeder Artikel/Kommentar korrekt publisiziert oder versteckt.
Diese Zeit sollte daher nicht verändert werden (außer ein Artikel soll bewußt eine andere Position auf der absoluten Zeitleiste erhalten, d.h. real früher oder später erscheinen, nicht nur gemäß einer anderen Ortszeit).
txp ist an dieser Stelle ja korrekt.
Unglücklicherweise aber wird dieser Zeitstempel in einigen Fällen falsch berechnet .

B-2 revidiert
Momentan wird auch die konventionelle Zeit verwendet [siehe A-2].
Und zwar für die Zeiteingabe (manuell oder automatisch) und für die Zeitausgabe.
Alle Berechnungen werden momentan aufgrund einer einzigen Zeitregel in den zwei Einstellungen Zeitzone und Sommerzeit/DST vorgenommen. Diese einzige Regel ist die “Normalzeit”, die für die Webseite gilt, also lokale Zeit der Webseite [A-4].

Notabene: Diese Zeitregel in Übereinstimmung mit der Zeit “draußen in der richtigen Welt” zu halten, ist Aufgabe des admin. Also z.B. im rechten Moment die Sommerzeiteinstellung vorzunehmen. Mehr dazu später.

Anhand der konventionellen Zeit erfolgen in txp also alle Zeiteinstellungen, die absolute Zeit wird nur intern geführt.

Genau in dieser Art, die konventionelle Zeit zu benützen, liegt der Fehler in txp:

txp berücksichtigt nur einen Aspekt der konventionellen Zeit: Es kennt nur die gerade im Moment gültige Zeit-Regel. txp berücksichtigt dagegen nicht, dass der absolute Zeitstempel möglicherweise mit einer anderen Zeitregel verknüpft sein muss, um die vom Benutzer gemeinte konventionelle Zeit richtig wiederzugeben.
Der kontextuelle Aspekt wird also nicht berücksichtigt.
(Kontextuell bedeutet hier: eingebettet in die wirkliche Zeit draußen, die mal so und mal so gilt und historisch, geschichtlich ist. Ein Artikel müsste demnach die Zeit behalten, die er damals auch wirklich hatte – und nicht eine zwar rechnerisch korrekte Zeit, die aber einem anderen Bezugssystem/Kontext angehört. Der Kontext ist: Die damals gültige Zeitzone/DST-Einstellung, nicht die gegenwärtig gültige. Genauso für Artikel, die in der Zukunft liegen: Es muss die dort gültige Zeitregel berücksichtigt werden.)

Dies führt dann schon bei der Berechnung, beim Erstellen eines Artikeln zu falschen Zeitstempeln:

z.B.: Ich erstelle zwei Artikel, die später veröffentlicht werden sollen – einer für Januar, einer für Juli. Jeder sollte nach meiner Vorstellung um 10:15 Uhr deutscher Zeit erscheinen. Also gebe ich unten beim Zeitstempel “10:15 Uhr” ein und das entsprechende Datum. Meine Zeitzone ist GMT+1 und es ist gerade Winterzeit. Im Juli aber wird es Somerzeit sein (das steht fest!). Die interne absolute Zeit des Zeitstempels wird nun aber für beide Artikel als “9:15 am GMT” berechnet. Das ist nicht korrekt! Es stimmt nur für den Januar. Für den Juli-Termin wäre die absolute Zeit, ausgedrückt in GMT, dagegen: “8:15 am GMT”!

txp hat leider nicht die geringste Erinnerung daran, welche Zeitregel zum Zeitpunkt des Zeitstempels gültig war. So welche Zeitzone damals eingestellt war, und ob Sommerzeit galt oder nicht.
Das heißt dann: Hier erfolgt doch eine Änderung der Zeit in dem Moment, in dem die Zeiteinstellungen geändert werden. Zwar werden die Ziffern des GMT-Stempels nicht angerührt, aber das originale Bezugssystem wird verändert.
Die originale Zeitinformation = absolute Zeit in GMT + kontextuelle (bis dahin webseitenweite) Einstellung von Zeitzone und Sommerzeit, geht verloren.
Sie war nur durch die Kombination des absoluten Zeitstempels in der Datenbank und der Zeiteinstellung im Admin-Bereich korrekt vorhanden. Wenn sich eines ändert, ändert sich die kontextuelle konventionelle Zeit bzw. geht die originale Zeit verloren.

Durch Anwendung einer neuen Zeitregel (konventionelle Zeit, z.B. Winterzeit) auf Zeitstempel, die ihren Ursprung in einer anderen Zeitregel (z.B. Sommerzeit) haben, wird aber eine falsche Information generiert – und dies geschieht noch dazu jedesmal aufs neue, wenn sich etwas ändert.

B-3 revidiert
An diesem Punkt braucht txp meiner Meinung nach ganz klar eine Verbesserung:
txp müsste die korrekte Beziehung zwischen konventioneller Zeit und absoluter Zeit für jeden Zeitpunkt berücksichtigen und diese Information auch behalten. Dies muss eigentlich für jeden einzelnen Artikel/Kommentar geschehen.

(jedenfalls meiner Meinung nach, weil es mehr Möglichkeiten eröffnet und am sichersten ist. Es gibt evtl. eine Möglichkeit ohne das auszukommen, dann braucht es aber eine umfangreiche Datenbank mit allen vorhandenen Zeitregeln auf aller Welt. s.u.)

Für eine optimale Funktion brauchen wir unbedingt beide Teile der Zeitinformation:

  • Die absolute Zeit wird für den richtigen Zeitpunkt zur Veröffentlichung und für die Sortierung der Artikel in Bezug aufeinander benötigt. Anders gesagt: Für die Beziehung zwischen Artikeln. Und sie wird als einfachste und praktischste Basis für die Berechnung aller Zeitangaben benötigt. [Natürlich könnte man auch überall nur die konventionelle Zeit zusammen mit ihrer Kennung/Regel speichern. Auch diese lassen sich ineinander umrechnen und vergleichen, aber dazu braucht man eine vollständige, lückenlose Tabelle aller vorhandenen Zeitregeln mit allen Daten, Ausnahmen und Brüchen.]
  • Die natürlich korrekt eingestellte _konventionelle Zeit (oder mindestens für jeden Artikel die vollständige zum Zeitpunkt des Zeitstempels gültige Regel, egal ob vergangen, aktuell oder in Zukunft zu veröffentlichen) wird für die korrekte Präsentation der Zeit benötigt, um den Artikel mit der in seinem gültigen Kontext (“draußen, richtige Welt”) geltenden Zeit anzuzeigen. Vor allem brauchen wir das, wenn es darum geht, dass Artikel zu bestimmten Zeitpunkten in der wirklichen Welt veröffentlicht werden bzw. wieder verschwinden, also in Kalendern oder Veranstaltungslisten. [ob der gültige Kontext “draußen” dann eine gemeinsame Zeit auf der Webseite oder evtl. sogar eine differenziert Zeitangabe je nach Herkunft des Artikels/Kommentars ist, is davon noch unahängig, das ist eine Frage der Ansicht]

Meine Folgerung: Beide Informationen müssen in der Datenbank bei einem Artikel/Kommentar gespeichert werden.
Es gibt keinen Weg darum herum [unter bestimmten Voraussetzungen doch, s.u.].
Weil beide Teile einen wichtigen Teil der Gesamtinformation enthalten.

B-4 revidiert
Worauf sollen nun die verschiedenen Zeitangaben angewendet werden? Was ist ihre Funktion?

Die absolute Zeit (A-1) ist nötig, um den richtigen Zeitpunkt der Publikation des Artikels einzustellen (oder eben, wann er ausgeblendet wird), sowie für das richtige zeitliche Anordnen der Artikel untereinander. Es bestimmt die Reihenfolge, in der die Artikel angezeigt werden, wenn sie zeitlich geordnet sind. Durch die absolute Zeit wird die historische Reihenfolge der Artikel beibehalten, in der sie entstanden sind (oder eben veröffentlicht werden sollen, wenn es sich um time=future-stamps handelt)

Die (kontextuelle) konventionelle Zeit (A-2) wird verwendet, um die Zeiten richtig handzuhaben und zu präsentieren (z.B. wenn ich jetzt eine Veranstaltung für den nächsten Sommer poste und 15 Uhr angebe, innerhalb meiner Zeitzone aber eben damit MESZ statt MEZ meine). Die konventionelle Zeit betrifft nämlich die Relation der Artikel zu ihrer Umgebung in der wirklichen Welt/Zeit der Benutzer.

Last edited by saccade (2006-12-10 11:38:17)

Offline

#7 2006-12-10 23:49:09

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Als Zusammenfassung hier ein “Fahrplan”, wie der Umgang mit der Zeit in txp ist und wie er sich ändern müsste, um fehlerfrei zu sein:

  1. Die Verarbeitung der Zeitangaben in txp erfolgt intern nach einer normalisierten Referenzzeit (GMT), die für alle Installationen an allen Orten gleich ist (gespeichert im Zeitstempel).
  2. Die Zeiteingabe und die Zeitausgabe für einen Artikel/Kommentar erfolgt anhand einer konventionellen Zeitangabe, die für den Benutzer die normale Ortszeit ist. (wenn er sich innerhalb der selben Zeitzone befindet wie die Installation.)
  3. Diese konventionelle Zeitangabe wird durch eine Zeitregel definiert, die ihren Abstand zur Referenzzeit angibt.
  4. Diese Zeitregeln sind mancherorts immer gleich (etwa: eine Stunde später als GMT).
  5. Mancherorts wechseln sie aber auch und gelten so nur für bestimmte Zeiten (etwa: im Winter eine Stunde, im Sommer zwei Stunden später als GMT).
  6. Die konventionelle Zeit hat im letzteren Fall kontextuell unterschiedliche Abstände zur Referenzzeit. Beispiel: 10 Uhr deutscher Zeit ist im Winter = 9 Uhr GMT, im Sommer dagegen = 8 Uhr GMT
  7. txp verarbeitet aber für jede konventionelle Zeitangabe und alle Zeiten nur eine einzige, die gerade aktuelle Zeitregel (aus Zeitzone und DST). Beispiel: Momentan deutsche Zeit, GMT+1
  8. txp kommt so für Zeitangaben, für die eine andere Regel gilt, zu falschen Ergebnissen bei der Berechnung der Referenzzeit. Beispiel: Wenn ich heute (10.12.2006) für einen Artikel nach deutscher Zeit die Publikationszeit 1.1.2007 10 Uhr angebe, für einen anderen die Publikationszeit 1.7.2007 10 Uhr, dann setzt txp für beide die Referenzzeit bzw. den Zeitstempel intern auf 9 Uhr GMT. Das aber ist falsch. Für den 1.7.2007 wäre 8 Uhr GMT richtig.
  9. Das fällt so lange nicht auf, so lange die zur Berechnung der Referenzzeit verwendete Zeitregel auch die gerade gültige Zeitregel ist. Bei der Anzeige wird der Rechenfehler ja wieder nach der gleichen Regel rückgängig gemacht.
  10. Sobald sich aber die Zeitregel ändert, tritt der Fehler zutage. Beispiel: Ich ändere zur gegebenen Zeit die Zeitregel. Sie lautet dann im Sommer: GMT+2.
  11. Durch die falsch berechnete Referenzzeit stimmen sowohl ggf. die Publikation als auch die Anzeige der konventionellen Zeit nicht mehr mit der eingegebenen konventionellen Zeit überein. Beispiel: Der Artikel wird zeitstempelgemäß um 9 Uhr GMT veröffentlicht – das ist aber im Sommer in Deutschland dann schon 11 Uhr deutscher Zeit und nicht wie gewünscht 10 Uhr. Bei der Berechnung nach der geltenden Regel wird die Zeitanzeige des Artikels nun auf 11 Uhr gesetzt.
  12. Lösungen:
  13. Bei der Eingabe muss der Zeitstempel anhand der korrekten Zeitregel erfolgen, d.h. es muss für die eingegebene Zeit die richtige Regel ermittelt werden.
  14. Für die aktuelle Zeit ist das die aktuelle Regel (ausgehend davon, dass sie richtig gesetzt wurde).
  15. Für manuell eingegebene Zeiten muss die Regel ermittelt werden, was anhand einer Tabelle geschehen muss, da die Sommerzeitregeln ja keiner Formel folgen, sondern willkürlich gesetzt sind.
  16. Das bedeutet, dass es eine entsprechende Tabelle geben muss, die für jede Zeitzone definiert, wann welche Sommerzeitregel gilt.
  17. Für die Ausgabe der Zeit muss ebenfalls ermittelt werden, welche Zeitregel zu dieser Zeit greift, und dann die ausgegebene Zeit entsprechend berechnet werden.
  18. Auch dazu ist eine vollständige Tabelle erforderlich.
  19. Für die Entscheidung, welcher Artikel nach der time=past/future-Einstellung angezeigt werden soll, genügt dagegen die nunmehr korrekt berechnete Zeitstempel-Zeit nach GMT.
  20. Weitere Überlegungen:
  21. Nachdem nun nach 15+18 sowieso eine Tabelle mit den geltenden Regeln für Sommerzeit erforderlich ist, könnte überlegt werden, ob diese nicht in die Einstellung der Zeitregel integriert wird. Dann wäre nur noch die Wahl der gewünschten Zeitzone erforderlich – die richtige Einstellung für die Sommerzeit würde ja in den Berechnungen schon enthalten sein. Für die Einstellung der internen Installationszeit kann dann die Tabelle verwendet und so die Sommerzeit automatisch für txp eingestellt werden.
  22. Die Tabelle mit den Sommerzeitdaten könnte am besten analog zu den Sprachdateien zentral gepflegt (z.B. von hilfsbereiten txp-Benutzern auf dem neuesten Stand gehalten) werden und von Zeit zu Zeit per Update von den admins aktualisiert werden.
  23. Noch weitergehende Überlegungen:
  24. Es gibt einen kleinen Problempunkt: Die Sommerzeit führt zu zwei Effekten, die besonderer Behandlung bedürfen:
  25. Beim Wechsel von Winter- auf Sommerzeit wird die Uhr eine Stunde vorgestellt. Gibt ein Benutzer manuell zufällig als gewünschte Publikationszeit die nicht vorhandene Stunde an, müsste eine Fehlermeldung erfolgen oder besser die Zeit automatisch korrigiert werden, d.h. eine Stunde später eingeordnet werden (und dann nach neuer Zeitregel berechnet werden, damit der Zeitstempel stimmt). Beispiel: Mit 2.30 Uhr der nicht vorhandenen Stunde zwischen 2 und 3 Uhr ist logischerweise 3.30 Uhr gemeint.
  26. Beim umgekehrten Wechsel von Sommer- auf Winterzeit wird die Uhr ja um eine Stunde zurückgestellt, es gibt sie also nach deutscher Zeit doppelt (nach GMT nicht). Wird dabei ein Artikel manuell auf die doppelt vorhandenen Stunde gestempelt, dann müsste angegeben werden, welche der beiden Zeiten gemeint ist, die nach Winterzeit oder die nach Sommerzeit. Der Benutzer/Autor müsste also die Zeitregel auswählen können. Würde andererseits ein Artikel etwa um 2.30 Uhr der Sommerzeit gepostet und so angezeigt, danach eine Stunde später um 2.30 der Winterzeit ebenfalls ein Artikel, dann wäre es gut, wenn für beide die gerade geltende Zeit angegeben würde. Nach den Sommerzeitregeln in Deutschland hilft man sich auch mit der Angabe 2.30A Uhr oder 2.30B Uhr.
  27. Es ist also durchaus darüber nachzudenken, ob man nicht den Zeiten überhaupt Zeitstempel mitgibt, die auch die anzuwendende Regel mit angeben. Das könnte in Form einer Auswahlliste erfolgen.
  28. Ist das der Fall, dann kann evtl. auch ein erweitertes Zeitmenü implementiert werden, das es dem Benutzer/Autor generell erlaubt, bei der Eingabe seiner gewünschten Zeit die ihm geläufige Zeitzone zu verwenden. (Dann könnte er auch auf Reisen seine Ortszeit widerspiegeln)
  29. Für die Ausgabe kann dann überlegt werden, ob man die Benutzerauswahl als Basis für die Zeitausgabe “durchreicht”, d.h. die Artikel mit der vom Benutzer/Autor verwendeten Uhrzeit und Zeitzone auszeichnet – oder aber alle Artikel normalisiert und nach einer Zeitregel anzeigen lässt.
  30. Auch wenn man die Einstellung der Zeitregel nicht dem Benutzer überlässt, kann ein Speichern der verwendeten Zeitregel zusammen mit dem Zeitstempel vorteilhaft sein: Für einen Serverumzug in eine andere Zeitzone (oder ein Umstellen) hätten dann die bisherigen Artikel die Originalzeitzone bei sich und könnten bei Bedarf mit deren Zeiteinstellungen angezeigt werden. Die neuen würden durch die Umstellung ja die neue Zeitregel tragen und ebenfalls nach ihren Originalregeln dargestellt werden.

Last edited by saccade (2006-12-10 23:55:37)

Offline

#8 2006-12-11 01:09:41

ruud
Developer Emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: [de-de] (Sommer-) Zeitproblem

Punkt 16: Sommerzeit aendert sich nicht nur pro Zeitzone, sondern auch pro Land und manchmal auch pro Jahr. Das wird eine ziemlich grosse Tabelle.

Offline

#9 2006-12-11 07:43:39

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Hi ruud,
danke für die Antwort :-)

grosse Tabelle: Ja, das ist so.

Obwohl: Dann auch wieder nicht soo groß.

Hier ist z.B. eine Übersicht zu finden
(hier für alle Länder, dort dann jeweils Link zur Sommerzeittabelle
Termine bis 2013 für Europa

Ideal wäre natürlich eine komplette Tabelle, ein Pluspunkt für txp :-)

Aber praktisch könnte man das so handhaben:
Zunächst werden die Termine von den meisten ja für eine beschränkte Zeitspanne (also sagen wir 2000 bis 2010 gebraucht).
Dann auch von den meisten nur für eine Zeitzone (wer nicht die umfassendere Lösung will).

D.h.
man könnte die Zeittabelle splitten und für jede Zeitzone extra erstellen und wie die Sprachdateien nur bei Bedarf installieren lassen.

Die Vervollständigung mit den historischen Sommerzeiten oder weiter in die Zukunft erfolgt dann später und wird per update der Zeitdatei übernommen.
(über die historischen Zeiten kann man diskutieren: kann txp sie überhaupt verwalten oder sind sie sowieso außerhalb des Bereichs der Computerzeit, d.h. können sie als Zeitstempel gar nicht auftreten? Praktisch brauchen wird sie kaum jemand.)

Offline

#10 2006-12-13 11:49:05

saccade
Plugin Author
From: Neubeuern, Germany
Registered: 2004-11-05
Posts: 521

Re: [de-de] (Sommer-) Zeitproblem

Es ist leider noch eine Korrektur fällig. Sorry.

Beim Suchen nach gangbaren Änderungen bin ich darauf gestoßen, dass ich den Zeitstempel in txp mißverstanden habe.
Da mein Server GMT als Serverzeit verwendet, dachte ich, dass diese als Grundlage für den Zeitstempel dient (dieser also als “absolute Zeitreferenz” konzipiert ist).
Das ist wohl so nicht richtig.
Stattdessen wird die Serverzeit verwendet. Und diese Zeit ist eine relative/konventionelle Zeit.
Die Serverzeit wird aber gar nicht 1:1 übernommen, sondern modifiziert via GMT und die txp-internen Einstellungen.

D.h. das ganze Zeitproblem beruht auf der Weise, wie die Serverzeit sich zur konventionellen Zeit (Lokalzeit) verhält:
  • Verhält sich die Serverzeit parallel zur Lokalzeit inklusive ihrer Zeitumstellungen (!) und entsprechen auch die txp-Einstellungen dieser Zeit, dann ist es wohl so, dass gar kein Zeitfehler auftritt (kann mir das vielleicht irgendjemand bestätigen?).
  • Unterscheidet sich dagegen die Serverzeit im Hinblick auf die DST zeitweise von der Lokalzeit (entweder, indem sie gar keine Zeitumstellung mitvollzieht oder diese zu anderen Zeiten vornimmt), dann kommt es zu den Verschiebungseffekten.

Ich werde das ganze nochmal nachkontrollieren und durchdenken und dann in den obigen Posts die entsprechenden Korrekturen nachvollziehbar eintragen.

Immerhin habe ich inzwischen auch eine saubere Trennung der verschiedenen Aspekte und Anforderungen gefunden und will diese später posten, wenn ich nochmal drüber nachgedacht habe ;-)

Last edited by saccade (2006-12-13 11:49:38)

Offline

Board footer

Powered by FluxBB