Eintragsdetails ansehen
| ID | Projekt | Kategorie | Sichtbarkeit | Meldungsdatum | Zuletzt aktualisiert |
|---|---|---|---|---|---|
| 0001410 | Eressea | General | öffentlich | 2008-04-19 19:06 | 2015-07-06 15:31 |
| Reporter | Apexo | Bearbeitung durch | Enno | ||
| Priorität | normal | Schweregrad | Unschönheit | Reproduzierbar | immer |
| Status | geschlossen | Lösung | nicht reproduzierbar | ||
| Zusammenfassung | 0001410: 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 :-) | ||||
| Tags | Keine Tags zugeordnet. | ||||
| Partei | orkx | ||||
| Spiel | |||||
| Report | |||||
|
so the obvious fix I see here is: convert all times to GMT before comparing |
|
|
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.
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. |
|
|
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 |
|
|
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. |
|
|
kann ich NICHT bestätigen, dass das jetzt besser funktioniert
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. |
|
|
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. |
|
|
Ich aknn das weiterhin nicht reproduzieren, und habe auch von anderer Seite noch keinerlei Meldungen bekommen, vermute hier ein Phantom. |
|
| Ä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 |