Closed Bug 25177 Opened 23 years ago Closed 20 years ago

Date should be shown differently depending on the todays date.


(SeaMonkey :: MailNews: Message Display, defect, P3)



(Not tracked)



(Reporter: bugzilla, Unassigned)




(1 file, 6 obsolete files)

- If a mail or a news posting is less than 24 hours old only the time should be 

- 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 
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
Hey, I can cry too!
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.
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 :-)
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 

Anyway, I'll probably go along with the "Help Wanted" idea as I've now managed 
to become completely de-sensitized to all this.  :^)
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
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?).
OS: Windows 98 → All
Hardware: PC → All
netscape 4.x has this
Keywords: 4xp
I just saw that something got checked in that looks like this bug....
Perhaps it could be fixed to work the way 4x worked?
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
or something like that...
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.

The patch allows the date to be formatted in any way supported by the
nsIScriptableDateFormat. For this, three preferences are evaluated:    - for messages which are from today
mail.ui.display.dateformat.thisweek - for messages which are not older than a
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
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 ....
Keywords: patch
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
keep in sync with the 1.1Beta sources
Attachment #87645 - Attachment is obsolete: true
removing "helpwanted", adding "review"
Keywords: helpwantedreview
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.

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, 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.

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.
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?
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 ....
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.
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.
> 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.

removing the review keyword, not that it seems there's something left to do :)
Keywords: review
any interest in handling pathalogical cases where the either
the user or the message sender have their system clocks set

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.

s/not/now/ in comment 26 :)

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

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]


[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 .....
* 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
another update, correcting a typo
Attachment #93602 - Attachment is obsolete: true
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 

I'd like to leave it this way by default. If folks feel a hidden pref is 
desirable, thats fine with me.
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?)

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.

Mail/News UI specs can be found here:

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. 
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
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.
Attachment #93672 - Attachment is obsolete: true
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);
    nsCOMPtr<nsIPrefBranch> prefBranch; 
    rv = prefs->GetBranch(nsnull, getter_AddRefs(prefBranch)); 
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 );
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 on attachment 105498 [details] [diff] [review]
updated to David's requests

Attachment #105498 - Flags: superreview+
Fix checked in
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.3alpha

I tried to use this 'hidden' feature by adding the following

user_pref("", 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
*** Bug 200903 has been marked as a duplicate of this bug. ***
I'm fine to have 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 ?
> 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 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?
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("", 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:-)

I can confirm it is fixed on windows 2000 build 2003050211
Just needs to be documented somewhere !

Thanks to all
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.