Opened 9 years ago

Closed 9 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:
Has a Patch: no Platform: All


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)

parsedate.diff (1.1 KB ) - added by czeidler 9 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 by axeld, 9 years ago

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.

comment:2 by stippi, 9 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 czeidler, 9 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 czeidler, 9 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 czeidler, 9 years ago

Cc: "Axel Dörfler" <axeld@…> added

comment:6 by axeld, 9 years ago

Cc: "Axel Dörfler" <axeld@…> 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 czeidler, 9 years ago

Attachment: parsedate.diff added

comment:7 by czeidler, 9 years ago

Hi Axel, could you check this patch? not sure if it is fixed at the right place... thanks

comment:8 by axeld, 9 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 czeidler, 9 years ago

Resolution: fixed
Status: newclosed

Ok thanks! optimized it and committed it in hrev41146.

Note: See TracTickets for help on using tickets.