25177 - Date should be shown differently depending on the todays date.

Status: RESOLVED FIXED

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

Description

[Henrik Gemal]

- 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

[Phil Peterson]

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.

Comment 2

[Robert John Churchill]

Hey, I can cry too!

Comment 3

[scottputterman]

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

[Phil Peterson]

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

[Robert John Churchill]

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

[Robert John Churchill]

Releasing to the universe...

Comment 7

[lchiang]

using new keyword field to track.

Comment 8

[Richard Zach]

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

Comment 9

[Henrik Gemal]

netscape 4.x has this

Comment 10

[Henrik Gemal]

I just saw that something got checked in that looks like this bug....
Perhaps it could be fixed to work the way 4x worked?

Comment 11

[Henrik Gemal]

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

[Frank Schönheit]

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

[Frank Schönheit]

Attachment: preference-dependent display format for message date

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

[Frank Schönheit]

Attachment: preference-dependent display format for message date

updated the patch so that now the settings are shared between different view
instances (like it happens for nearly all other sttings there).

Comment 15

[Frank Schönheit]

Attachment: preference-dependent display format for message date

keep in sync with the 1.1Beta sources

Comment 16

[Frank Schönheit]

removing "helpwanted", adding "review"

Comment 17

[David :Bienvenu]

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

[Frank Schönheit]

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

[David :Bienvenu]

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

[Frank Schönheit]

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

[David :Bienvenu]

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

[Frank Schönheit]

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

[Frank Schönheit]

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

[David :Bienvenu]

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

[m_mozilla]

> 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

[Frank Schönheit]

removing the review keyword, not that it seems there's something left to do :)

Comment 27

[m_mozilla]

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

[Frank Schönheit]

s/not/now/ in comment 26 :)

Comment 29

[Frank Schönheit]

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

[Frank Schönheit]

Attachment: preference-dependent display format for message date

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"

Comment 31

[Frank Schönheit]

Attachment: preference-dependent display format for message date

another update, correcting a typo

Comment 32

[jglick]

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

[Frank Schönheit]

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

[Frank Schönheit]

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

[jglick]

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

[Frank Schönheit]

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

Comment 37

[Jason Bennett]

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

[Frank Schönheit]

Attachment: same as before, updated to 1.2b branch

Comment 39

[David :Bienvenu]

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

[Frank Schönheit]

Attachment: updated to David's requests

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

Comment 41

[David :Bienvenu]

Comment on attachment 105498 [details] [diff] [review]
updated to David's requests

sr=bienvenu

Comment 42

[Jean-Francois Ducarroz]

Fix checked in

Comment 43

[Olivier Vit (just a reporter)]

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

[Mike Cowperthwaite]

*** Bug 200903 has been marked as a duplicate of this bug. ***

Comment 45

[Olivier Vit (just a reporter)]

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

[Frank Schönheit]

@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

[Olivier Vit (just a reporter)]

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

[Olivier Vit (just a reporter)]

Hi

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

Thanks to all