Eintragsdetails ansehen

IDProjektKategorieSichtbarkeitZuletzt aktualisiert
0001410EresseaGeneralöffentlich2015-07-06 15:31
ReporterApexo Bearbeitung durchEnno  
PrioritätnormalSchweregradUnschönheitReproduzierbarimmer
Status geschlossenLösungnicht reproduzierbar 
Zusammenfassung0001410: server doesn't take time zone into account when comparing sent time in order mails
Beschreibung

I've sent two mails with orders, first with Date: Sat, 19 Apr 2008 17:53:39 +0200 second with Date: Sat, 19 Apr 2008 17:48:48 +0100 (GMT+01:00)

Obviously, the second was sent after the first one, however since the time zone changed as well, the server doesn't recognize this and sends a warning email, indicating that it would ignore the second mail.

Zusätzliche Informationen

Okay, this is mostly relevant when the time zone changes (eastwards, i.e. from GMT+x to GMT+y with y<x), which happens at least once per year for many countries.

For me this is an issue because I've set up an automated script that does the automated stuff and sends in basic orders (which I make of use of when going to vacations), however the scripts also sends orders when I'm not on vacation, and apparently it uses another time zone. So for the moment I'm forced to wait for an hour before the server accepts my mail ... I'm a bit lazy to change my script, so I hope the server will be fixed :-)

TagsKeine Tags zugeordnet.
Parteiorkx
Spiel
Report

Notizen / Dateien

Apexo

Apexo

2008-04-19 19:09

Reporter   ~0003421

so the obvious fix I see here is: convert all times to GMT before comparing

Enno

Enno

2008-05-17 01:57

Administrator   ~0003475

Ich behandle die Header mit parsedate(), und das macht das korrekt:

Python 2.4.4 (#2, Apr 5 2007, 20:11:18) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

from email.Utils import parsedate, parseaddr from time import mktime, ctime, sleep, time d1="Sat, 19 Apr 2008 17:48:48 +0100 (GMT+01:00)" d2="Sat, 19 Apr 2008 17:53:39 +0200" parsedate(d1) (2008, 4, 19, 17, 48, 48, 0, 1, -1) parsedate(d2) (2008, 4, 19, 17, 53, 39, 0, 1, -1)

Es kann also and er Zeitzone nicht liegen. Ich denke, wenn wir dem wirklich auf den Grund gehen, dann brauche ich mal ein aktuelles Beispiel dazu, mit frischen Mails, am besten an einem Montag produziert, weil mir das mehr Zeit zum debuggen gibt.

Apexo

Apexo

2008-05-17 04:15

Reporter   ~0003477

und genau da ist doch der Bug, parsedate scheint die Zeitzone völlig zu ignorieren ... die erste Mail von Sat, 19 Apr 2008 17:53:39 +0200 [15:53 GMT] wurde ja ca. 55min vor der zweiten abgeschickt, Date: Sat, 19 Apr 2008 17:48:48 +0100 (GMT+01:00) [16:48 GMT]

wenn man die Zeitzonen ignoriert - wie parsedate - dann sieht es halt eher so aus, als wäre die zweite Mail 5min vor der ersten gesendet worden.

Scheinbar gibt es dafür aber eine Lösung, in Form von parsedate_tz aus email.utils:

parsedate_tz(d2) = (2008, 4, 19, 17, 53, 39, 0, 1, -1, 7200) parsedate_tz(d1) = (2008, 4, 19, 17, 48, 48, 0, 1, -1, 3600)

da steht dann die Zeitzone mit drin, wie man das jetzt einfach auf GMT o.ä. normalisiert weiß ich aber auch nicht, im Zweifelsfall halt mit datetime.datetime(2008, 4, 19, 17, 53, 39) - datetime.timedelta(seconds=7200) ...

hab ich jetzt nur in Python 2.5 getestet, weiß ich also nicht ob es die auch schon in Python 2.4 gibt

Enno

Enno

2008-05-17 10:08

Administrator   ~0003478

Man beachte, wie spaet es gestern schon war... Ich haette im Bett sein sollen. Ja, Du hast recht, und danke fuer den parsedate_tz Hinweis. In kombination mit mktime_tz (beide in rfc822) geht das jetzt ordentlich.

Apexo

Apexo

2008-10-17 17:07

Reporter   ~0003714

kann ich NICHT bestätigen, dass das jetzt besser funktioniert

  1. Mail: Date: Fri, 17 Oct 2008 16:49:21 +0200 (CEST) (14:48 UTC)

  2. Mail: Date: Fri, 17 Oct 2008 14:58:53 +0000 (UTC)

und die Warnung: Es erreichte uns bereits ein Zug mit einem späteren Absendedatum (Fri Oct 17 16:49:21 2008 > Fri Oct 17 14:58:53 2008). Entweder ist deine Systemzeit verstellt, oder ein Zug hat einen anderen Zug von dir auf dem Transportweg überholt. Entscheidend für die Auswertungsreihenfolge ist das Absendedatum, d.h. der Date:-Header deiner Mail.

Enno

Enno

2014-08-14 06:09

Administrator   ~0005324

Passiert das noch immer? Ich habe seit dem letzten Kommentar hier die Skripte so gut wie nue geschrieben, und der Server ist umgezogen, das könnte den Fehler ja behoben haben.

Enno

Enno

2015-04-05 11:53

Administrator   ~0005709

Ich aknn das weiterhin nicht reproduzieren, und habe auch von anderer Seite noch keinerlei Meldungen bekommen, vermute hier ein Phantom.

Eintrags-Historie

Änderungsdatum Benutzername Feld Änderung
2008-04-19 19:06 Apexo Neuer Eintrag
2008-04-19 19:06 Apexo Partei/Faction => orkx
2008-04-19 19:09 Apexo Notiz hinzugefügt: 0003421
2008-05-17 01:57 Enno Notiz hinzugefügt: 0003475
2008-05-17 04:15 Apexo Notiz hinzugefügt: 0003477
2008-05-17 10:08 Enno Status neu => erledigt
2008-05-17 10:08 Enno Lösung offen => erledigt
2008-05-17 10:08 Enno Bearbeitung durch => Enno
2008-05-17 10:08 Enno Notiz hinzugefügt: 0003478
2008-05-17 14:17 Enno Behoben in Version => 572
2008-05-17 14:28 Enno Kategorie -none- => email
2008-07-20 11:11 Xolgrim Status erledigt => geschlossen
2008-10-17 17:07 Apexo Notiz hinzugefügt: 0003714
2008-10-17 17:07 Apexo Status geschlossen => Rückmeldung
2008-10-17 17:07 Apexo Lösung erledigt => wiedereröffnet
2014-08-14 06:09 Enno Notiz hinzugefügt: 0005324
2015-04-05 11:53 Enno Notiz hinzugefügt: 0005709
2015-04-05 11:53 Enno Status Rückmeldung => erledigt
2015-04-05 11:53 Enno Lösung wiedereröffnet => nicht reproduzierbar
2015-07-06 15:31 Enno Status erledigt => geschlossen