Martin Wodrich <[EMAIL PROTECTED]> wrote on 05.10.04:
> Michael Heydekamp <[EMAIL PROTECTED]> schrieb am 04.10.04 um 18:09:
>> Der Bug liegt, wenn man den Code liest, so klar vor einem wie nur
>> was. Manchmal kann man sich nur wundern, wie so etwas �ber 10 Jahre
>> lang unentdeckt bleiben konnte.
> Indem genau der Bug eben in der Praxis total selten auftrat. Solange
> man keinen Codereview macht, sieht man sowas einfach nicht.
> Genau soclhe Stellen sind es aber unter Umst�nden die eben eventuell
> doch mal echte Probleme machen. Nicht direkt diese Stelle, aber eben
> solche Stellen, die eben bei Tests �bersehen werden.
Eine "Kunst" beim Programmieren liegt halt auch darin, an (m�glichst)
alle F�lle zu denken.
Es ist aber auch wirklich zum K*tzen und ich scheine sowas irgendwie
anzuziehen: Eigentlich wollte ich nur dem "Date:"-Header die �bliche
Angabe des Wochentags spendieren, prompt sto�e ich erstmal auf den
obigen Bug. Ok, der war nicht so schwer zu fixen.
Aber *danach* bin ich im selben Bereich noch auf mehr Dinge gesto�en,
und die haben wieder dazu gef�hrt, da� ich praktisch alles komplett neu
schreiben mu�te, was mit der Erzeugung von Headern zusammenh�ngt, die
Angaben �ber Datum/Zeit/Zeitzone enthalten.
Einiges davon kann man hier vielleicht tats�chlich mal zur Diskussion
stellen, denn einige Fragen sind da durchaus noch offen.
Da ich mit der Dokumentation der bisherigen �nderungen gerade eben
fertig geworden bin, quote ich die nachfolgend einfach mal einzeln und
schreibe ein paar Kommentare und Fragen dazu:
----------8<----------
> 3. Die "From_"-Zeile von UUCP-Mails enth�lt nicht mehr Erstellungs-
> datum und -uhrzeit der Nachricht im RFC-Format (wie es im "Date:"-
> Header steht), sondern es wird eine Zeile mit dem *aktuellen*
> Datum/Uhrzeit im sog. "asctime()"-Format erzeugt:
> Jetzt : From my Wed Oct 6 19:08:33 2004 remote from freexp.de
> Bisher: From my 06 Oct 2004 19:08:33 +0200 remote from freexp.de
> Das RFC-Format ist sowohl laut der Beispiele in RFC976 als auch in
> der Praxis beim UUCP-Austausch an dieser Stelle zumindest un�blich,
> m�glicherweise sogar falsch.
----------8<----------
Das Format habe ich tats�chlich anhand realer UUCP-Messages verifiziert,
die mir von zwei verschiedenen Seiten zugeschickt wurden.
Dabei hat sich aber nicht nur das andere Format best�tigt, sondern auch,
da� nicht wie bisher die Erstellungszeit in den Header geh�rt, sondern
die aktuelle Zeit (wie sie auch in den "Received:"-Header geschrieben
wird.
Ich denke, das ist soweit eindeutig, es sei denn, jemand wei� mehr
dar�ber als ich sehen und recherchieren konnte.
Jetzt was Umfangreicheres, es geht um die Zeitzonenangaben:
----------8<----------
> 4. Bei Headern, die das aktuelle Datum/Uhrzeit enthalten ("Received:",
> "From_"-Zeile bei UUCP-Mails), wird die Zeitzone nicht mehr blind
> vom Erstellungsdatum der Nachricht �bernommen, da dies im Fall, da�
> Erstellungs- und Konvertierdatum in unterschiedlichen Zeitperioden
> liegen (Beispiel: Nachricht wird am Abend des letzten Tages der
> Sommerperiode erzeugt, aber erst in der Nacht oder am n�chsten
> Morgen konvertiert und versandt), zu einer falsch deklarierten
> Zeitzone f�hren w�rde - bzw. in der Vergangenheit auch konkret dazu
> gef�hrt hat.
> Stattdessen wird jetzt gepr�ft, ob Erstellungs- und aktuelles Datum
> in derselben Zeitperiode liegen. Ist dies nicht der Fall, wird die
> Zeitzone des aktuellen Datums aus der Zeitzone des Erstellungs-
> datums errechnet, indem je nach Konstellation 1 Stunde addiert
> (Winter => Sommer) bzw. subtrahiert (Sommer => Winter) wird. Liegen
> Erstellungs- und aktuelles Datum in derselben Zeitperiode, wird die
> Zeitzone aus dem Erstellungsdatum - wie bisher - unver�ndert �ber-
> nommen.
> Ma�gebend f�r die Definition der Zeitperioden ist ausschlie�lich
> die aktuell f�r die EU geltende Regelung, deren Algorithmus auch
> bei der automatischen Zeitumstellung in FreeXP verwendet wird. Die
> Angabe "S" bzw. "W" im ZConnect-Header ist unzuverl�ssig und wird
> wie bisher ignoriert.
> Das obige Verfahren funktioniert daher in allen F�llen zuverl�ssig,
> in denen die Konvertierung in einem Land stattfindet, in dem a)
> eine mit der in der EU g�ltigen Regelung identische Winter-/Sommer-
> zeitregelung angewandt wird, und b) dessen Zeitzone identisch ist
> mit dem Land, in dem die Nachricht erstellt wurde (was nahezu immer
> der Fall sein d�rfte). Mit anderen Worten: Bisher stimmte die Zeit-
> zonenangabe bei dem geschilderten Szenario praktisch nie, jetzt
> stimmt sie praktisch immer.
----------8<----------
Ich hoffe, das ist soweit verst�ndlich beschrieben. Wir (wie alle
anderen UUZs auch) haben also in bestimmten F�llen schlicht eine falsche
Zeitzone deklariert. Das funktioniert jetzt alles sehr sch�n wie oben
beschrieben und ist IMO umfassend getestet.
Was aber evtl. noch etwas st�rt, ist, da� man dabei an die
Winter-/Sommerzeitregelung der EU gebunden ist. Zwar wird FreeXP eher
wenig User in Marokko oder Australien haben ;), aber man k�nnte daran
denken, wie bei der Winter-/Sommerzeitumstellung in FreeXP selbst auch
im UUZ die TZ-Variable auszuwerten: Ist sie gesetzt, w�rde in jedem Fall
die sich daraus ergebende Zeitzone genommen und die im EDA:-Header
deklarierte Zone f�r die Erstellungszeit zwar f�r den "Date:"-Header,
nicht aber mehr f�r die aktuelle Zeitzone des Versands in "Received:"
bzw. "From_" (UUCP) verwendet.
Damit w�re man v�llig unabh�ngig und es g�be einen sinnvollen Weg, den
Default "EU" zu overriden. Was haltet Ihr davon?
Zwei andere Ideen dazu habe ich verworfen:
- Zeitzone vom Betriebssystem �bernehmen. W�re zwar unter Win2K/XP
mittels XP_NTVDM.DLL sicher m�glich, aber eben nur da. Win9x und DOS
w�ren au�en vor, Linux Dosemu/DOSBOX und OS/2 wohl auch. K�me
h�chstens als weitere optionale M�glichkeit zur TZ-Variablen in
Betracht. Meinungen bitte.
- Zeitzone aus der XPOINT.CFG auslesen. Da diese zur Laufzeit des UUZ
statisch ist, sie sich aber w�hrend eines Konvertiervorgangs �ndern
kann, best�nde in diesem Fall wieder die Gefahr, eine falsche Zeitzone
zu deklarieren (w�hrend die oben beschriebene L�sung einen Wechsel der
Zeitperiode zur Laufzeit ber�cksichtigt, da Lokalzeit und Zeitzone
f�r jede Nachricht neu kalkuliert werden). Au�erdem wird gerade der
UUZ auch gerne in Umgebungen verwendet, in denen keine XPOINT.CFG
verf�gbar ist.
Von diesem Standpunkt w�rde ich ungerne abr�cken m�ssen. ;)
Die �brigen �nderungen nur zur Info, da sehe ich eigentlich keinen
Diskussionsbedarf:
----------8<----------
> 1. Die Header "Date:", "Received:", "From_" (nur UUCP-Mails) und der
> MIME-Parameter "modification-date=" enthalten neben Datum, Uhrzeit
> und Zeitzone jetzt auch den Wochentag in dem in RFC2822 definierten
> Format ("Mon, ", "Tue, " usw.).
> 2. Der "Date:"-Header wird nicht mehr als allererster Header, sondern
> im Anschlu� an den "Subject:"-Header geschrieben (Anpassung an
> �bliche Gepflogenheiten).
[...]
> 5. Enth�lt der EDA:-Header keine Zeitzonenangabe, gelten automatisch
> jetzt MEZ (=CET, =UTC+1, Winter) bzw. MESZ (=CEST, =UTC+2, Sommer)
> als Defaultwerte, da die Angabe einer Zeitzone im "Date:"-Header
> gem�� RFC2822 Pflicht ist und die bisherige Angabe von "?0000" (mit
> einem beliebigen und zufallsabh�ngigen Zeichen als "Vorzeichen")
> unbrauchbar war.
> 6. Ist der EDA:-Header leer bzw. existiert �berhaupt nicht, wird statt
> eines ung�ltigen "Date:"-Headers mit dem Inhalt " Jan :: 0000"
> jetzt ein g�ltiger Header mit dem aktuellen Datum/Uhrzeit und der
> Zeitzone MEZ/MESZ im korrekten Format erzeugt (da der Header
> Pflicht ist, war der totale Verzicht keine Option).
> 7. Bei der Datums-/Zeitangabe von Dateien (Quelle: DDA:-Header) im
> MIME-Parameter "modification-date=" wird als Zeitzone nicht mehr
> "+0000", sondern "-0000" deklariert. Das negative Vorzeichen signa-
> lisiert gem�� RFC2822, da� keine Information �ber eine Zeitzone
> vorliegt, w�hrend "+0000" signalisiert, da� es sich exakt um die
> Zeitzone "UTC" handelt.
> 8. Bei allen anderen Zeitzonenangaben wird eine evtl. als "W-0" oder
> "S-0" im EDA:-Header deklarierte Zeitzone zu "+0000" korrigiert und
> konvertiert.
> 9. (Zu sp�ter) Y2K-Fix: Bei einer Nachricht, die am ersten Tag eines
> neuen Jahrhunderts zu einer Uhrzeit erzeugt wurde, zu der das kor-
> respondierende Datum in UTC-Zeitrechnung noch im alten Jahrhundert
> lag (in unserer Zeitzone also am 01.01.2000 zwischen 00:00 und
> 00:59 Uhr, in Australien zwischen 00:00 und 11:59 Uhr), dann wurde
> bei der Konvertierung - und zwar unabh�ngig davon, wann und wo
> diese stattfand - f�lschlicherweise das Jahr "1900" statt "2000"
> deklariert, weil aus der den lokalen Zeitstempel (und nur ein zwei-
> stelliges Jahr) enthaltenden Variable 'hd.datum' das Jahrzehnt "00"
> und aus der den UTC-Zeitstempel (und ein vierstelliges Jahr) ent-
> haltenden Variable 'hd.zdatum' das Jahrhundert �bernommen und so zu
> "1900" zusammengesetzt wurde. Dieser Fall wird jetzt korrekt behan-
> delt, was sich in der Praxis aber erst wieder in gut 95 Jahren
> positiv bemerkbar machen wird, wenn der letzte FreeXP-User kurz
> nach Silvester tapfer seine Neujahrsgr��e verfa�t. ;-)
----------8<----------
Ich h�nge im Followup zu diesem Posting mal die zentralen neuen Routinen
f�r das ganze Ged�nse an.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
