|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
12 Jul 2023, 06:48 PM | #1 |
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
Warning: incorrect result from search after:
Search after:<date> erroneously includes messages on <date>!
Seemingly search has mistaken after:<date> to mean after:<date and time 00:00:00.000...0>. FM Support says the team "suggested that this behaviour is expected" |
13 Jul 2023, 09:57 AM | #2 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
In my view, this behaviour is acceptable, but should be documented.
|
13 Jul 2023, 04:52 PM | #3 |
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
|
13 Jul 2023, 07:46 PM | #4 | |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 492
|
Quote:
Users on the other hand are not expected to (need to) understand anything about the underlying architecture. There is, in my view, no good reason why a search that specifies "after a date" should not mean exactly what it does in everyday life. If I say I'll do something "after Wednesday" I would not expect anybody to think I might start on Wednesday. Moreover, FM's GUI search interface lacks immediately visible documentation. There's no indicator that "after" might not be intuitive, and no link to a help page. So no normal user is ever going to find their way to the documentation, such as it is. Currently the search help page says nothing at all about "after date" meaning "after the first nanosecond of that day". There's a principle, "least astonishment", that's used in some programming languages and in interface design - see: https://en.wikipedia.org/wiki/Princi...t_astonishment - in which interfaces are meant to be designed so that they'll do what most users would expect. My view would be that this feature violates that principle. Last edited by JeremyNicoll : 13 Jul 2023 at 07:52 PM. |
|
13 Jul 2023, 08:04 PM | #5 | |||
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
Quote:
I can see no grounds to doubt the implementation is simply defective. FM's denial disconcerts me. Quote:
Quote:
PS FM would find this tricky to fix without perturbing existing stored searches. Last edited by chrisjj : 13 Jul 2023 at 11:24 PM. |
|||
14 Jul 2023, 02:14 AM | #6 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
When you only specify a date range, number of decisions needed to be made. Whether after:2023-07-13 means all messages received after 00:00 on 2023-07-13 or 23:59 on 2023-07-13 is only one of them. Should you use a neutral time zone like UTC? Should you use the time zone that the user was employing at the time the message was received? Is the right option the time zone of the user currently running the search (in which case two people making the same search of the same shared folder would get different results)? And so on ... The most important thing is that the results are well defined and documented.
Literally person centuries of talented IT professional time was invested to deal with all the complications around date and time handling in POSIX. |
14 Jul 2023, 02:18 AM | #7 | |
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
Quote:
Sure, but I can't see how any of that relates to this issue. After = after. |
|
14 Jul 2023, 03:00 AM | #8 | ||
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
If you are the person sending, receiving and searching for the email, everything is simple (as long as JMAP and Fastmail are aware of that). In the general case, the most important thing is to know what the search actually does (which the current documentation does not tell you). NOTE: Actually, the behaviour of JMAP after is (inadequately) documented in https://jmap.io/spec-mail.html#emailquery Quote:
Last edited by BritTim : 14 Jul 2023 at 03:09 AM. |
||
14 Jul 2023, 03:20 AM | #9 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Further to my last message, note that Fastmail needs to document that you can specify something like
Code:
after:"2023-07-13 06:00" |
14 Jul 2023, 03:26 AM | #10 | |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
Quote:
|
|
14 Jul 2023, 08:31 PM | #11 | ||||
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
Quote:
Quote:
Quote:
Quote:
NOTE: Actually, the behaviour of JMAP after is (inadequately) documented in https://jmap.io/spec-mail.html#emailquery Are we to know that FM searches are "JMAP"? On "inadequate", I agree. e.g. "after: UTCDate The receivedAt date-time of the Email must be the same or after this date-time to match the condition." UTCDate is undefined. Woe betide anyone who guesses it is a date... given it is here apparently being compared to a date-time. Did someone/thing overlook a type conversion error? Oops. It shouldn't default at all. Day means day - all of it. |
||||
14 Jul 2023, 08:33 PM | #12 |
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
|
15 Jul 2023, 06:44 PM | #13 | |
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 492
|
Quote:
Yes, but whether they document it or not (somewhere the user is not going to find unless they search for it) is not really the point. That level of detail (and timezones etc) is API detail. Also, we don't know whether the search process looks at the dates within headers (ie in the exact character by character format they are in, possibly malformed) or whether it's looking at validated binary dates extracted from emails and stored in FM's indexes. The user interface is dumbed-down/vague to the point where whatever interpretation a user puts on something is going to be "normal everyday usage" so "after date" should mean what it would do in ordinary life. A big part of the problem is that the user interface is set up so that a user can type something generic into a box (and hope that the system will interpret it the way they expect). The only immediately visible hint is that one could type eg "25 Nov" or "last Wednesday". There may be lots of other formats that work, but there's no clue in thatt dialog box what they are. Rather than just have a single unformatted field where a user can type something, I think the box that opens up when you choose "After" should be two boxes, with both date and time. The date box could offer a dropdown so one could pick a date from a calendar widget, or something like "last Xxxday" .. and - if 00:00:00 is the implied time of day that should be prefilled in the time field. Yes of course this would be more complicated (for FM to code) but it would always be completely clear what value was going to be used. |
|
15 Jul 2023, 07:41 PM | #14 | ||
Cornerstone of the Community
Join Date: Jul 2003
Posts: 692
|
Quote:
[quote=JeremyNicoll;630135]The user interface is dumbed-down/vague to the point where whatever interpretation a user puts on something is going to be "normal everyday usage" so "after date" should mean what it would do in ordinary life.[quote=JeremyNicoll;630135] I think that's unfair on "after:". There's nothing dumb about it's interface. Even smart writers/readers knows "After 2023" means after 2023. What's dumb is only the implementation - where "after:2023" includes all emails in 2023. Quote:
Anyway, note were discussing the after: operator, not the After control where I believe the issues are different. |
||
16 Jul 2023, 03:58 AM | #15 | |||
Essential Contributor
Join Date: Dec 2017
Location: Scotland
Posts: 492
|
Quote:
You can't blame FM if the email itself contains more than one Date: header. Also, there's now a huge range of current and obsolete but still meant to be supported valid formats for parts of a date/time specification. See eg RFC5322. Quote:
Quote:
I've never used the "after:" operator at all, always used the Advanced Search GUI to specify what I want done. |
|||