Bug 54098

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