Opened 14 years ago
Closed 14 years ago
#7257 closed bug (fixed)
Mails from ALTERNATE GmbH have wrong date
| Reported by: | stippi | Owned by: | czeidler |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Servers/mail_daemon | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
After fetching my whole mailbox via IMAP, I have five mails from ALTERNATE GmbH that have a wrong date, namely the time when they were fetched. Opening these mails in Mail shows the correct date at which they were sent. This seems to be a problem specific to the formatting of these mails, as no other mails from any other sender exposes the problem.
Attachments (1)
Change History (10)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Yes, I can send such a mail as retrieved in Haiku zipped to someone interested in private. It possibly contains private information, which is why I didn't attach one directly to the ticket.
comment:3 by , 14 years ago
The mail attributes are parsed using an optimized algorithm while Mail uses the old one. So the problem should be there. If its ok just send the header part of the mail. Or the header part with the date...
comment:4 by , 14 years ago
What date was it? Have one mail with a date something like 28.2.10 (28 Feb 2010) but parsedate read 1910. Axel what do you think? Is there a way to tell parsedate which century the date is?
By the way Mail just display the date string.
comment:5 by , 14 years ago
| Cc: | added |
|---|
comment:6 by , 14 years ago
| Cc: | removed |
|---|
Even though it got the job done to let me have another look, I'm on the bug list, and get all bug updates, anyway.
parsedate() already gets a time_t as the reference date. This is used to resolve relative dates like "yesterday". Since "10" as year could be considered as relative, one could use this mechanism to solve it. As an additional refinement, dates far in the future could be moved into the previous century, though (not sure if that should be done, though, opinions welcome -- this was just a common solution to deal with the millenium date changes).
by , 14 years ago
| Attachment: | parsedate.diff added |
|---|
comment:7 by , 14 years ago
Hi Axel, could you check this patch? not sure if it is fixed at the right place... thanks
comment:8 by , 14 years ago
It looks okay, even though localtime_r() is now called even when not needed, ie. it could be optimized a bit.
In any case, there is a ParseDateTest in src/test/system/libroot/os/ that should work, and which you can use to a) test if nothing that worked is now broken, and b) add a test case that should be fixed by your changes :-)
comment:9 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Ok thanks! optimized it and committed it in hrev41146.
I guess it would be very helpful to attach such a mail, or offer to make it available to anyone wanting to work on that bug.