Version: 1.5 (using KDE 3.1.0) Installed from: Mandrake Linux Cooker i586 - Cooker Compiler: gcc version 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk) OS: Linux (i686) release 2.4.21pre3-3mdkcustom Hello, I received an email whose date is shown as unknow. In the header the date is listed as: Date: Tue, Feb 04, 2003 00:01:20 +0000 which seems to differ from other messages in that it has commas in it. Would it be possible to modify the parsing algorithm to handle dates of this format?
Interpreting non-standard dates is a wish.
I found another date that is parsed incorrectly. Hope this helps when someone gets around to fixing the date parser. I may do it if I manage to figure out the code... :) Date: Mon Dec 15 11:04:05 PST 2003
*** Bug 73585 has been marked as a duplicate of this bug. ***
*** Bug 73766 has been marked as a duplicate of this bug. ***
I can accept that support for nonstandard date formats is a wish, but when the BBC E-mail News Service generates them, I would suggest it is quite an important wish. I received one just like the last-mentioned: Date: Thu Feb 12 07:03:13 GMT 2004
Sorry, Ben, but the fact that the BBC E-mail News Service uses broken programs to send out their newsletters hardly qualifies as making this a more important wish (although I very well understand the inconvenience this is causing). I hope that you've already contacted the BBC ENS to tell them that they are sending out newsletters without standard-compliant Date headers.
Yes, I did contact the BBC. Sorry, Ingo, but the importance of this wish is defined by the users who have made the wish, and I'm one of them. If you want to judge importance by your own standards, then use a closed bug tracking system instead.
On Thursday 19 February 2004 05:17, Ben Davis wrote: > Sorry, Ingo, but the importance of this wish is defined by the users who > have made the wish, and I'm one of them. If you want to judge importance > by your own standards, then use a closed bug tracking system instead. Ben, if you think it's that important for you to get this issue fixed, then feel free to download the sources and provide a patch. IMO it's the developers' own decision what they consider most important to work on in the moment. Please remember that this is open source and also keep in mind that KMail is standard compliant while the date format used by BBC isn't.
I agree fully. In my opinion, the fact that this has been labelled as a wish as opposed to a bug report is adequate acknowledgement of your last sentence. My complaint is simply as follows. This bug tracker encourages users to specify what they consider important - quantitively with votes and by reasonable extension qualitatively with comments - and yet one of your developers (I'm assuming Ingo is a developer) went against me rather rudely when I did just that. You should provide a clear message as to whether your users' opinions are important to you. This is an open tracker, after all. Good work on KDE. Of course it is your choice what to work on and when. But it is my firm opinion that no amount of selfless open source work gives you an excuse to be rude to people without good reason.
On Freitag, 20. Februar 2004 00:46, Ben Davis wrote: > Good work on KDE. Of course it is your choice what to work on and when. > But it is my firm opinion that no amount of selfless open source work > gives you an excuse to be rude to people without good reason. As we agree that it's still a wish ;-) please let's clear another misunderstanding. Ingo is a developer (actually the maintainer) and his answer certainly wasn't meant to be rude. Perhaps you don't know that many of the KMail developers aren't native English speakers. So it may happen that one or another statement is understood as being rude although it wasn't intended so at all. Additonally only a few people deal with all the tons of reports about KMail problems, wishes, etc. They don't complain, but they have to be effective. So it might happen that an answer is not long enough for an outsider while the developer already has written more than usually and necessary (in his opinion). Users (in positive sense) also don't know about the preferences in the development which are made for a certain timeframe or release. Sometimes a change seems to be so simple however it doesn't fit into what the developers do in that moment. The problem remains registered in the bug tracking system. It might be the next issue to be worked on or not. But who knows... I hope I can convince you at least a little to change your mind about KMail development and developers. Enjoy KDE 3.2 and KDEPIM 3.3 once it will be out. Regards, Andreas PS. Sorry, but even I can't tell you when this date parsing problem will be fixed.
Wow. You seem to be reading a lot into my last post that I didn't say. What exactly am I supposed to change my mind about? Ingo's message quite clearly says, "Your opinion is wrong and you shouldn't have posted it here." I don't think you can reasonably argue that a language barrier is involved here; I can easily imagine a native English speaker making the same post, for either of the following reasons. It's possible that Ingo missed the point of my first post. I was merely adding myself to the set of people who would like to see the wish implemented. He may have felt I was attacking KMail; I was not. It's also possible that I was right all along and my opinion was rejected without good reason. Who knows, right? In any case, I am sorry for being excessively rude in my first reply. (See, I can do it too: underestimate how rude I'm being!)
I see this is a problem: I received recently mail with Date: header field in form: Date: Tue Mar 23 18:00:02 2004 KMail showed date as 01.01.1970 01:00 (according to my locale) According to RFC822 header should be: ================================= 5. DATE AND TIME SPECIFICATION 5.1. SYNTAX date-time = [ day "," ] date time ; dd mm yy ; hh:mm:ss zzz ================================= As you see, header of message was not RFC822 compliant and KMail was in its right to not parse this but "be tolerant what you receive".
Ha, maybe Date: Tue Mar 23 18:00:02 2004 isn't RFC compliant, but is POSIX compliant - check man ctime(1)
Unfortunately for those of us who want this bug fixed^H^H^H^H^H^H^H^H^Hwish granted, one of the RFCs does say explicitly that ctime's result does not pass as a valid Date header. :/ (Incidentally, ctime is in section 3 of the manual for me.)
@comment #2 and #5: this format has been implemented with https://bugs.kde.org/show_bug.cgi?id=117848#c1 The one from the original report is something I'm currently doing.
SVN commit 1017430 by mkoller: FEATURE: 54098 Allow another non-RFC2822 conforming date to be parsed to be more tolerant. Added unit test M +34 -18 dw_date.cpp [POSSIBLY UNSAFE: scanf] M +6 -0 tests/CMakeLists.txt A tests/testdateparser.cpp [License: LGPL (v2)] A tests/testdateparser.h [License: LGPL (v2)] WebSVN link: http://websvn.kde.org/?view=rev&revision=1017430
Git commit d1786732b10d1df4e73fe3aac034d4db6d05447b by Martin Koller. Committed on 14/07/2012 at 11:11. Pushed by mkoller into branch 'KDE/4.9'. enhance date-time parser to allow formats which were possible in KDE3 Related: bug 260761 M +65 -17 kmime/kmime_header_parsing.cpp M +39 -0 kmime/tests/auto/headertest.cpp http://commits.kde.org/kdepimlibs/d1786732b10d1df4e73fe3aac034d4db6d05447b
Git commit 7d8bbdfb09965fc0a2ec1bfdf1bb290497fa5464 by Martin Koller. Committed on 14/07/2012 at 11:11. Pushed by mkoller into branch 'master'. enhance date-time parser to allow formats which were possible in KDE3 Related: bug 260761 M +65 -17 kmime/kmime_header_parsing.cpp M +39 -0 kmime/tests/auto/headertest.cpp http://commits.kde.org/kdepimlibs/7d8bbdfb09965fc0a2ec1bfdf1bb290497fa5464
Git commit 72d7e6063c2cf275ad9a09669357b8c7bcfc2d69 by Martin Koller. Committed on 14/07/2012 at 11:11. Pushed by mkoller into branch 'KDE/4.8'. enhance date-time parser to allow formats which were possible in KDE3 Related: bug 260761 M +65 -17 kmime/kmime_header_parsing.cpp M +39 -0 kmime/tests/auto/headertest.cpp http://commits.kde.org/kdepimlibs/72d7e6063c2cf275ad9a09669357b8c7bcfc2d69