Bug 111633

Am Sonntag, 28. August 2005 09:23 schrieb p92@free.fr:
> Date: Mon, 27 Aug 1956 21:31:46 +0200


Can you try to copy such a message and manipulate the Date: header? Does the 
correct date show up if you remove the "Mon, " sequence?

Well I tried what you suggest, but date is always displayed as unknown in each case (suppressing 'Mon,' or just ',').

I don't know what function is used to parse the Date: but it can be naturally strange to interpret dates with a year of 1956, ie: before 01/01/1970. Is there a lower date limit in the date parser?

It might be wise to distinguish in kmail :
- an 'invalid' date - parser says date is in error or invalid format
- a 'missing' date - Date: header is missing in mail

FYI: In mimelib/dw_date.cpp I find:

	/* Additional check to limit valid range to 1970 to 2037 */
	if ((n >= 1970) && (n < 2038))
		year = n;
	else
		isValid = 0;

I receive spam messages with the following Date-header:
Date: Tue, 19 Jan 2038 11:14:07 +0800
Apparently the check in mimelib displays this as an invalid date, which is what I see in kmail (unknown).
In my view the range of invalid dates should be widened (1000 till 9999?). And it should be flagged as incorrect; not as unknown.
What does the RFC specify as a correct date?

in kde 3.5.4  I noticed that invalid dates are triggered when I set the fancy format for dates in the configuration. 

Created attachment 29717 [details]
Screenshot with "unknown" error

I can confirm this bug for kmail 1.10.92 in the current (11.1) OpenSUSE. I have a bunch of e-mails which were displayed correctly until yesterday (or a few days ago, not sure), but now they show up under "Unbekannt" (German for "unknown").

By the way: How do I set smaller fonts for those date bars?

(See screenshot in #6 ... didn't know how to attach a screenshot to this reply.)

Johannes

KMail Version 1.11.2 Using KDE 4.2.2 (KDE 4.2.2)
After upgrade from KDE 4.2.1 to 4.2.2 I see this bug: date field _sometimes_ is shown as "Unknown". When I am looking to any such a message, it is corrected and stays corrected. I tried removing of indexes of mail folders, but it didn't help. It is not funny to look at every message in my mail folders.

Looking at the description it looks like some commenters of this bug are actually experiencing something similar to bug #180267 (date lost, date rescued when clicking on the message).

This bug is still present in KMail 1.12.0. KDE 4.3. German locale (which was US English for a short time, maybe that causes this problem?).

At the end of the e-mail list KMail displays the groups "Yesterday", "Today" and below that a group named "Unknown" with about 50 e-mails. Just like in Johannes' screenshot attachment.

When I click on one of the e-mails with "unknown" date, the pointer jumps to the correct date and shows the e-mail (but it's still listed in the "unknown" group - I can go there and click on it and it jumps again ...).

Deleting the index files doesn't help.

Why is this bug still unconfirmed?

I just found out that I could remove the last (!) e-mail from the "unknown" group by just clicking on it, so that I could empty the whole (!) group (which is not displayed anymore).

Don't know if it works like this for others though. It's still a bug.

This bug report is only about the unrecognized (limited) year in the date format.
The reason is the current internal implementation which uses seconds since 1970 (which is the 0-time in UNIX like OSes).
Probably it will be possible to fix it once kmail uses the new KMime library ...

checking current KDE/4.9 kmime code, the KMime::DateFormatter methods internally still use time_t and therefore limit the possible time to 1.1.1970.

This bug has only been reported for versions before 4.14, which have been unsupported for at least two years now. Can anyone tell if this bug still present?

If noone confirms this bug for a Framework-based version of kdepim (version 5.0 or later, as part of KDE Applications 15.08 or later), it gets closed in about three months.

Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.