Closed
Bug 25177
Opened 25 years ago
Closed 22 years ago
Date should be shown differently depending on the todays date.
Categories
(SeaMonkey :: MailNews: Message Display, defect, P3)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.3alpha
People
(Reporter: bugzilla, Unassigned)
References
Details
Attachments
(1 file, 6 obsolete files)
5.49 KB,
patch
|
Bienvenu
:
superreview+
|
Details | Diff | Splinter Review |
- If a mail or a news posting is less than 24 hours old only the time should be shown. - If a mail or a news posting is more than 24 hours old but less than a week old, the weekday plus the time should be shown. - If a mail or a news posting is more than a week old, the full date should be shown.
Comment 1•25 years ago
|
||
Oh, man, we just can't win with this. Lots of people griped when we did it the old way, as you described. Now, it's easier for us to show all of the dates in the same format, so we do that, figuring to make the gripers happy. Turns out some people liked the old way. I know this is the point where someone usually chimes in "make it a user choice then!" If we were going to make this a pref, it would have to be done by rjc in the RDF group, so I'm reassigning to him, and cc'ing putterman so he can laugh or cry or whatever.
Assignee: phil → rjc
Comment 2•25 years ago
|
||
Hey, I can cry too!
Comment 3•25 years ago
|
||
I'm not going to laugh or cry but suggest this is not worth changing or providing an option for unless someone wants to do it as a Help Wanted bug.
Comment 4•25 years ago
|
||
Yah, I would have made it a helpwanted bug if the fix was in our area. Since it's an RDF issue, I figured Robert can make the call. And I wanted him to share our pain :-)
Comment 5•25 years ago
|
||
Actually, this *could* be done in several ways... One way to do the logic in RDF. Another way would be for all the logic to be in Mail/News: when RDF asks Mail/News for the date value for sorting (either via "#date?collation=true" or "#date?sort=true") you could return the nsIRDFDate value, and when RDF asks Mail/News for the date value for display (just the "#date") you could calculate whatever the appropriate string is to display and return that as a nsIRDFLiteral. Anyway, I'll probably go along with the "Help Wanted" idea as I've now managed to become completely de-sensitized to all this. :^)
Comment 6•25 years ago
|
||
Releasing to the universe...
Assignee: rjc → nobody
Summary: Date should be shown differently depending on the todays date. → [HELP WANTED] Date should be shown differently depending on the todays date.
Whiteboard: HELP WANTED
using new keyword field to track.
Keywords: helpwanted
Summary: [HELP WANTED] Date should be shown differently depending on the todays date. → Date should be shown differently depending on the todays date.
Whiteboard: HELP WANTED
Comment 8•24 years ago
|
||
I liked the old way, too. All those numbers in the date column make me dizzy. "Thu 24 Feb" would be so much easier to read. Maybe we can just have the day of week added to the date string, so I can more easily find that email I got last Monday (what date was that again?).
Reporter | ||
Comment 10•23 years ago
|
||
I just saw that something got checked in that looks like this bug.... Perhaps it could be fixed to work the way 4x worked?
Reporter | ||
Comment 11•23 years ago
|
||
the current work that's done in Mozilla mail, that only the time is shown when the mail is from today. How is that done? Backend or in .properties files? There should be 3 formats in the properties file dateToday dateWeek dateOther or something like that...
Comment 12•22 years ago
|
||
The code for formatting the date of less-than-a-week-old messages separately is already in nsMsgDBView.cxx, but commented out. There is an comment saying "we need a preference for this". I'd have a patch which enables this code again (means it steps in immediately before formatting the date for display), dependent on a preference setting. Unfortunately, it's _one_ preference only, not three as Henrik suggested in comment #11. If we come to a consensus about _what_ preferences to use, I'm willing to give it a try to implement it. Frank
Comment 13•22 years ago
|
||
The patch allows the date to be formatted in any way supported by the nsIScriptableDateFormat. For this, three preferences are evaluated: mail.ui.display.dateformat.today - for messages which are from today mail.ui.display.dateformat.thisweek - for messages which are not older than a week mail.ui.display.dateformat.default - for all other messages All three settings are an integer, which equals to the enum type defined in the nsIScriptableDateFormat, means: const long dateFormatNone = 0; // do not include the date in the format string const long dateFormatLong =1; // provides the long date format for the given locale const long dateFormatShort =2; // provides the short date format for the given locale const long dateFormatYearMonth =3; // formats using only the year and month const long dateFormatWeekday = 4; // week day (e.g. Mon, Tue) If the preferences doe not exist (or a value is invalied), they default to 0, 2, 2, respectively, means the behaviour does not change compaired to before. No user interface is added for the preferences, and changes require a restart of mozilla (no observer for the respective settings). Any comments (about the preference names or whatever) welcome ....
Comment 14•22 years ago
|
||
updated the patch so that now the settings are shared between different view instances (like it happens for nearly all other sttings there).
Attachment #82005 -
Attachment is obsolete: true
Comment 15•22 years ago
|
||
keep in sync with the 1.1Beta sources
Attachment #87645 -
Attachment is obsolete: true
Comment 17•22 years ago
|
||
adding self and Jennifer to cc list. Thanks for working on this, Frank. I've cc'ed Jennifer because this feature would be a lot more useful with a UI for chosing the date formats. I'm not sure how I feel about having the view code needing to read the preferences but it might be OK, assuming we feel these should be global preferences.
Comment 18•22 years ago
|
||
David, what would be the alternative to the view reading the preferences? Initializing it from the outside with the settings? And what would be the alternative to global preferences? per-account settings? per-identity settings? Admittedly, I did not think deeper about the kind of preferences - thinking about myself, I want this setting to be all the same globally, so I went for something similar like the label color settings in the view .... However, if we say we want some other kind of settings (though I at the moment can't imagine the use of a per-whatever setting :), I'll go for it. For the UI: well, would be interesting to do. I'd give it a try, but remembering the longish discussions about the UI of some other features I've seen in Bugzilla, I think I am not courageous enough to come up with a design myself :), so I'm counting on Jennifer here :) Frank
Comment 19•22 years ago
|
||
Frank, yes to all of your first set of questions. I think a global setting is the way to go, but surprisingly, often people have opinions completely at odds from mine :-) The fact that the view code has not had to access prefs before is what makes me reluctant to add prefs code to it now, but that might be the right thing to do. For the UI, I would like to hear what Jennifer thinks too. As a global setting, it would probably go in the top-level mail & newsgroup general settings, though that prefs page is pretty full. I'm not sure if this is worth a UI or not, but it is one of those things that people feel strongly about.
Comment 20•22 years ago
|
||
David, correct me if I'm wrong, but doesn't the nsMsgDBView already deal with preferences? It already loads (and monitors) the preferences for the label colors ... Seeing this, maybe the "Labels" page in the "Mail & Newsgroups" group would be a place to put the UI in - we could rename the page to something more general, and use the empty space there .... Finally, both settings affect the display of the message headers in the respective pane.
Comment 21•22 years ago
|
||
ah, silly me, you're right. Why did you chose to cache the prefs service pointer? If the label code doesn't, there's no reason for you to, either. You're only going to ask for those prefs once, right?
Comment 22•22 years ago
|
||
ah, yes. The caching of the pointer is a relict from the time where I read the 3 settings on demand only, instead of caching them themself. The same holds for EnsurePreferenceService, which then would not be needed anymore in this form. Will change this ....
Comment 23•22 years ago
|
||
one thing I'm not happy with currently is in the handling of ThisWeek messages: the old (commented) as well as the new code simply use the difference between the system and the mail date, and if this is less than 7 days, the week format is used. The problem with this is messages which are from "nearly one week" ago. For instance, if on Monday, at 8 am, I read messages from the last monday, 10 am, then the date will be shown as "Mon 10:00". This may suggest that the mail is from today, because people may tend to look at the day mainly, and not compare the message date with the system date. At least this is what I usually stumble upon ... Especially if there is another mail nearby which is from 7 am - it is displayed as "Mon 07:00". For my personal taste, this not enough to distinguish, as it always requires the user to be aware of the current time. I wonder if it would make sense to change the ThisWeek condition so that for example on Moday, at 8 am, only messages which are not older than 6*24+8 (instead of 7*24) hours are formatted in the ThisWeek format.
Comment 24•22 years ago
|
||
Frank, yeah, if today is monday, messages from last monday should show up with the full date - I'm not quite sure of the time math to do that.
Comment 25•22 years ago
|
||
> if today is monday, messages from last monday should
> show up with the full date - I'm not quite sure of
> the time math to do that
get current date
get time of last second in current day
get time of one week prior to last second in current day
call that last thing 'cutoff' (in seconds past epoch)
if message timestamp > cutoff, use "day of week" format
else use "full date" format
The above only applies to messages which aren't being shown in "today/yesterday"
type format. Today/yesterday would work similarly, but going back 24/48 hours
from last second in today's date instead of 7days back.
-matt
Comment 26•22 years ago
|
||
removing the review keyword, not that it seems there's something left to do :)
Keywords: review
Comment 27•22 years ago
|
||
any interest in handling pathalogical cases where the either the user or the message sender have their system clocks set incorrectly? Should messages from tomorrow say "tomorrow", or just show the full date? It would be confusing if today is monday and messages from six days ago say Tuesday (day of week format) and messages from tomorrow say Tuesday (also day of week format) I know I get mail from folks with their time zone set wrong. I could see the following making sense for me: message older than a week from end-of-day = date format message age is 24-48 hours from end-of-day = "today" or "yesterday" future message from w/in 24 hours of end-of-day = "tomorrow" future message from beyond 24 hours of end-of-day = date format yes, the above is not precise about boundary conditions, but you get the idea. -matt
Comment 28•22 years ago
|
||
s/not/now/ in comment 26 :)
Comment 29•22 years ago
|
||
matt, no problem with the boundaries, and I agree with the general idea of the limits. I think I will go and implement it the way that the limits are not "now minus 24 hours" and "now minus 7 days" (like originally suggested in this bug, and like the old code did), but "most recent midnight" and "most recent midnight minus 6 days". However, I do not really like the idea of "today" and "yesterday", nor this somewhat ... strange "tomorrow". For the first: If we omit the time, this will be important information lost. If we don't omit it, valueable space is wasted on the screen. For the second: The information got from a "tomorrow" is only that the sender did not configure her client/system correctly. Well, I do not think that most people want to know this. It's something you will see nearly equally easily from the date alone, so why using this "tomorrow" except that it's funny? [1] Frank [1] Yes, lot of things in mozilla is just because it's funny, and in general, I like this attitude :), but in this case .... I'm not sure .....
Comment 30•22 years ago
|
||
updated: * no caching of the preference service pointer anymore * week boundary is "most recent midnight minus 6 days" * day boundary unchanged - despite what I said before, the original code already respected the current day, and did not check for "now minus 24 hours"
Attachment #93126 -
Attachment is obsolete: true
Comment 31•22 years ago
|
||
another update, correcting a typo
Attachment #93602 -
Attachment is obsolete: true
Comment 32•22 years ago
|
||
The current date display is per design based on feedback from 4.x See comment #6 in Bug 112523: >Current day mail is shown only with time stamp, like (10:21 AM). All other days >are shown with complete day/time (12/17/2001 3:55 PM). >This was done to make the newest mail, that received today, stand out, while >mail from the previous day and past all share the consistent format of Date >Time. I'd like to leave it this way by default. If folks feel a hidden pref is desirable, thats fine with me.
Comment 33•22 years ago
|
||
So, Jennifer, you are suggesting not to have an UI for these preferences? From my experience, every once in a while people are complaining "Mozilla only shows the time of the mails, not the date!", while they are simply missing the fact that this holds for today's messages only. So I believe there is enough irritation about the current behaviour, to make more obvious what's going on, which could be done by an UI. The current patch defaults to the behaviour of the unpatched version, and as specified (btw: is there a place where one can read such specs?) Frank
Comment 34•22 years ago
|
||
If there is an agreement about that we want to have a pref for this, but no consensus yet about the UI, then I'd like to separate the UI question into another bug, which we then can fix separately or close as WONTFIX. Opinions?
Comment 35•22 years ago
|
||
Mail/News UI specs can be found here: http://www.mozilla.org/mailnews/specs/ Prefs are useful, but i think we need to be careful which ones we make visible in the UI. We tend to overload the visible prefs. If dups of this request are primarily coming from bugs and mozilla newsgroups, its probably something to consider for a hidden pref. If requests are coming from user feedback forms and help desk support requests, its something to consider for a visible pref.
Comment 36•22 years ago
|
||
Jennifer, thanks for the spec link and the explanation. Given your maasures, this would be a candidate for a hidden pref. -> adding keyword "review" again, as I consider the current fix to be complete then ...
Keywords: review
Comment 37•22 years ago
|
||
Is there some plan to list the "hidden prefs" somewhere obvious? Even though I follow bugzilla, I'd rather not have to search for an hour to find out that the problem I'm having could have been solved in five minutes.
Comment 38•22 years ago
|
||
Attachment #93672 -
Attachment is obsolete: true
Comment 39•22 years ago
|
||
sorry for taking so long to look at your latest patch, Frank. You should use the newer method for getting the pref service and reading prefs: nsCOMPtr<nsIPrefService> prefs = do_GetService(NS_PREFSERVICE_CONTRACTID, &rv); NS_ENSURE_SUCCESS(rv,rv); nsCOMPtr<nsIPrefBranch> prefBranch; rv = prefs->GetBranch(nsnull, getter_AddRefs(prefBranch)); NS_ENSURE_SUCCESS(rv,rv); and then use prefBranch to read the prefs. indentation is funny here: tabs? if so, please remove the tabs. + + // derivees + LL_MUL( microSecondsPerDay, secondsPerDay, microSecondsPerSecond ); + LL_MUL( microSecondsPer6Days, microSecondsPerDay, 6 ); + +
Comment 40•22 years ago
|
||
Thanks for looking at this, David. The latest version obtaines the preferences in the new way (should have stolen the preference code from the proper place :), and does not contain tabs anymore ....
Attachment #103453 -
Attachment is obsolete: true
Comment 41•22 years ago
|
||
Comment on attachment 105498 [details] [diff] [review] updated to David's requests sr=bienvenu
Attachment #105498 -
Flags: superreview+
Comment 42•22 years ago
|
||
Fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•22 years ago
|
Target Milestone: --- → mozilla1.3alpha
Comment 43•21 years ago
|
||
Hi I tried to use this 'hidden' feature by adding the following user_pref("mail.ui.display.dateformat.today", 0); user_pref("mail.ui.display.dateformat.thisweek", 4); user_pref("mail.ui.display.dateformat.default", 2); in either pref.js and user.js, and it doesn't display messages of the current week with only the day of the week Where am I wrong ? Can the use be documented somewhere ? with example ? refering to http://bugzilla.mozilla.org/show_bug.cgi?id=25177#c13
Comment 44•21 years ago
|
||
*** Bug 200903 has been marked as a duplicate of this bug. ***
Comment 45•21 years ago
|
||
I'm fine to have http://bugzilla.mozilla.org/show_bug.cgi?id=200903 be a duplicate of this bug, it is really what I meant. But I tried to implement what seemed to be the directives to get the expected result (see #c43), and I couldn't make it work as expected on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030406. Until proper description of the test case / sample to verify it is fixed, I can't understand how it could be considered as fixed. Isn't it fair ?
Comment 46•21 years ago
|
||
@Oliver > Until proper description of the test case / sample to verify it is fixed, I > can't understand how it could be considered as fixed. Please see http://bugzilla.mozilla.org/bug_status.html for the difference between FIXED and VERIFIED (I think the latter is what you mean). > in either pref.js and user.js, and it doesn't display messages of the current > week with only the day of the week I have to admit that the functionality here works for me since quite a while, out-of-the-box (means for a fresh moz installation, without patching it myself), and I know of quite some reports from people for who it works, too. So perhaps you're doing something differently, or something is different in your env. I use "4" for the week display, too, and I see only the week day - except the time, of course. What is "about:config" telling you in about the three pref(s) in question? Perhaps it's not properly read into moz?
Comment 47•21 years ago
|
||
Franck Thanks for your feedback I have tried it again on 1.3 (and not Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030406) I have a user.js file in the profile folder with the following: user_pref("mail.ui.display.dateformat.today", 0); user_pref("mail.ui.display.dateformat.thisweek", 4); user_pref("mail.ui.display.dateformat.default", 2); about:config is consistent And the result is : it works ! But I can't manage to make a more recent version work, then I can't test again:-)
Comment 48•21 years ago
|
||
Hi I can confirm it is fixed on windows 2000 build 2003050211 Just needs to be documented somewhere ! Thanks to all
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•