Sollte die E-Mail-Kopfzeile die Ortszeit oder die UTC-Zeit des Absenders sein?

Ich schreibe einen web-basierten E-Mail-Client in Python und es ist eine Frage entstanden, in welcher Zeitzone der "Date" -Header einer E-Mail wie beim Senden dargestellt werden soll.Sollte die E-Mail-Kopfzeile die Ortszeit oder die UTC-Zeit des Absenders sein?

RFC 2822 Zustände in Abschnitt 3.3, dass:

Das Datum und die Uhrzeit-Tag sollte Ortszeit auszudrücken.

Das scheint mir zweideutig; die Frage ist die Ortszeit von wem? Der E-Mail-Server oder der Absender? Natürlich würde ich den Absender annehmen (wer könnte in irgendeiner Zeitzone sein, und kann in ihren Kontoeinstellungen geändert werden). Weitere Verwirrung entstand, als ich Pythons email.utils.formatdate-Funktion betrachtete, die nur zwei Alternativen anzubieten scheint: UTC oder lokale Zeit (des Servers). Für mich scheint es keine Möglichkeit zu geben, eine alternative Zeitzone anzugeben, oder fehlt mir etwas?

Das Übergeben eines timeval an Formatdatum mit time.mktime(senders_tz_aware_now_datetime.timetuple()) führt zu einer UTC-Datumszeichenfolge, die sich falsch anfühlt, was der RFC oben sagt.

Also welche Zeitzone sollte "Date" sein, und existiert irgendeine Standardfunktion, um die passende Datumszeichenkette zu erstellen?

Quelle

2012-05-07 kuhnza

Verwenden Sie einfach UTC und Sie werden glücklicher sein.

Das ist was passiert, wenn Spezifikationen Begriffe wie SOLL verwenden. Ich denke, dass sowohl SOLL als auch die Spezifikationen verboten werden dürfen, weil sie immer unnötige Komplexität erzeugen.

Die Verwendung von UTC ist absolut gültig.

Quelle

2012-05-07 18:46:35 sorin

Das wird es nicht tun, ich konvertiere ein Zeitzone bewusste Datetime-Objekt mit dem Zeitplan Methode, was is_dst bereits festgelegt ist. Es beantwortet auch nicht meine Frage darüber, was die richtige Datum-Zeit-Darstellung ist. – kuhnza

Änderte meine Meinung, gehen Sie den einfachen Weg und Sie werden Zeit haben, ein Bier am Abend zu trinken. – sorin

Haha Ich mag deinen Stil. Trotzdem würde ich gerne eine Vorstellung davon bekommen, wie dies üblicherweise gehandhabt wird, weil ich mir vorstelle, dass es Auswirkungen auf eine Reihe von E-Mail-Clients hat, von denen ich noch nie gehört habe, geschweige denn die Zeit oder Ressourcen zum Testen. – kuhnza

Wenn Sie den RFC einhalten möchten, übergeben Sie localtime=True, die eine Datumszeichenfolge mit der Ortszeit und der richtigen Zeitzone zurückgibt (vorausgesetzt, Sie haben es richtig eingerichtet).

>>> email.utils.formatdate(localtime=True) 
'Mon, 07 May 2012 12:09:16 -0700'

Ohne localtime=True bekommen Sie ein Datum Zeichenfolge UTC Zeit darstellt:

>>> email.utils.formatdate() 
'Mon, 07 May 2012 19:08:55 -0000'

-0000 offenbar zeigt UTC, obwohl die RFC speziell mit +0000 empfiehlt. Nicht sicher, ob dies ein Fehler in email.utils ist.

Hier ist die relevante Python-Dokumentation:

Optional Lokalzeit ist ein Flag, dass, wenn wahr, timeval interpretiert und gibt ein Datum in Bezug auf die lokale Zeitzone statt UTC, richtig Sommerzeit zu berücksichtigen. Der Standardwert ist "Falsch", dh UTC wird verwendet.

Quelle

2012-05-07 19:11:26 spinlok

Danke, natürlich hatten wir das ursprünglich gedacht. Leider wirft Ihre Antwort genau die Frage auf, die mich stutzig gemacht hat: Was ist "die richtige Zeitzone"? Die Einstellung 'localtime = True' gibt die Zeitzone des Servers zurück, nicht den Absender. Daher meine Frage, sollte es die lokale Zeitzone des Servers oder des Absenders sein? Man würde annehmen, dass die Zeitzone des Absenders die richtige Sache ist. In diesem Fall kann ich jedoch nicht sehen, dass das Formatdatum die erforderliche Funktionalität dafür bereitstellt. – kuhnza

Es spielt keine Rolle, in welcher Zeitzone sich der Absender befindet, solange Sie einen konsistenten Zeitstempel generieren, der den Zeitpunkt angibt, zu dem die E-Mail gesendet wurde. Es liegt am Client des Empfängers, es richtig zu interpretieren. Deshalb schlug @Sorin vor, mit UTC zu gehen, was der einfachste Weg ist. – spinlok

Ich stimme zu, dass es egal ist, aber es stört mich, dass der RFC sagt, dass es als Ortszeit erscheinen sollte. – kuhnza

Dies kommt als ein Top-Ergebnis beim googlen "E-Mail-Client Ortszeit"; Leider adressieren die beiden Antworten und die begleitenden Kommentare die Python-Implementierung kaum und versäumen es, vollständig mit der Betreffzeile zu sprechen (was die Google-Antwort füttert).

Der RFC ist eindeutig, weil es offensichtlich ist: Der Header "^ Date:" ist lokal in dem Moment, in dem geschrieben wird. Der Mail-Client schreibt im Allgemeinen den Header "^ Date:" (in jeder der vielen Implementierungen, mit denen ich mich befasst habe). Bei den meisten (ordnungsgemäß konfigurierten) Clients ist dies die lokale Zeit, die vom Betriebssystem des Clients gemeldet wird.

Im Fall von Webmail könnte die lokale Zeit vom Benutzeragenten geliefert werden (der normalerweise seine lokale Zeit vom Betriebssystem erhält). Typischer würde es vom Benutzer innerhalb der Webanwendung (a la gmail) festgelegt werden.

Wichtig, wenn Sie "RFC folgen" (wahrscheinlich eine gute Idee für ein Netzwerkprotokoll), wird das resultierende Verhalten auf EMPFANGEN von Clients im Allgemeinen das Datum zeigen, dass die Mail gesendet wurde, wie vom Absender gesehen. Dies ist der springende Punkt von "SOLL" im RFC. Ich möchte nicht UTC sehen, wenn ich versuche herauszufinden, wann ein Kollege eine E-Mail geschickt hat. Ich will ihre Ortszeit. Auf diese Weise kann ich den Zeitunterschied in einem Schritt (ihre lokale Zeit zu meinem) herausfinden, nicht zwei (ihre lokale Zeit zu UTC zu meiner lokalen Zeit). Ich bekomme auch sofort Hinweise auf den Kontext ihrer Kommunikation (war es Nacht? Arbeitsstunden? Usw.).

Quelle

2016-01-20 22:22:16 ccy

Sollte die E-Mail-Kopfzeile die Ortszeit oder die UTC-Zeit des Absenders sein?

Antwort

Verwandte Themen