248808 - Search/filter/mailview: "date", "is after" includes messages on date

Status: RESOLVED FIXED

(MailNews Core :: Filters, defect)

Description

[[e-mail]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

When searching, you can choose to search by date. But searching with date and
"is after", also gives the results of the date you have choosen, even if you
meant "is after".
"Is before" works the right way.

Reproducible: Always
Steps to Reproduce:
1. Open search
2. Choose to search by date.
3. Choose "is after"
4. Type a date, where you know you have recived mails on that date and the date
after.
5. Search

Actual Results:  
If you search for 06-06-2004 (DD-MM-YYYY), the search results will include mails
from 06-06-2004.

Expected Results:  
If you search for 06-06-2004 (DD-MM-YYYY), the search results should include
mails from 07-06-2004, because the "is after" the date typed.

Tested on Thunderbird 0.7 on Windows XP.

Comment 1

[Wayne Mery (:wsmwk)]

this still occurs

Comment 2

[Anje]

Using Thunderbird 17.0.2
Problem still occurs.

additional:
Does not accept system date eg:
Date > is after > 28/01/2013
returns everything from 'wed 4/07/12   07:42PM  to current date

Comment 3

[Anje]

Additional:
Using windows vista, thunderbird 17.0.2
RE: search Messages:
Note:
1. does not search by system date eg: 12/02/2013
2. does not allow search by date and time

if I use eg: 2013/01/12 (no one uses this in UK and my computer is not set to use it and the returned results display as per system eg: Sat 26/01/13 07:30PM)

3. parameter = is after - does not return 'after' but includes that date.
4. parameter = is before - works

Comment 4

[:aceman]

Attachment: patch

So the bug was that the logic added 60*60*24 to the time variable to advance one day. However, the time variable was a PRTime which seems to be in nanoseconds. So 60*60*24 did not advance a full day. So that could get fixed by multiplying PR_NSEC_PER_MSEC. However I do not like such hardcoding of logic having assumptions about internal representation of the time. So I rewrote the functions to use the exploded time members which should be more future-proof. But I leave it to rkent to decide what is better.

Comment 5

[:aceman]

Attachment: patch v2

Comment 6

[Kent James (:rkent)]

Comment on attachment 747117 [details] [diff] [review]
patch v2

I like the version using exploded time everywhere. Thanks.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/4e6e804b478d

Comment 8

[:aceman]

Attachment: tests

Some tests for the bug.

Comment 9

[:aceman]

Comment on attachment 750679 [details] [diff] [review]
tests

This patch is not yet reviewed or checked in, but I apologize for adding it after the bug was fixed...

Comment 10

[Mark Banner (:standard8)]

Comment on attachment 750679 [details] [diff] [review]
tests

Review of attachment 750679 [details] [diff] [review]:
-----------------------------------------------------------------

Stealing review to get this closed off. r=Standard8

Comment 11

[:aceman]

Thanks!

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/86f91beced9f