218926 - No time zone information in attribution line of reply

Status: NEW

(MailNews Core :: Composition, defect)

Description

[Christian Eyrich]

When having mailnews.reply_header_type set to 2 or 3 date and time of the
original mail is printed to the attribution line. But a time zone information
for this time is missing.

We should provide information about the time zone the timestamp was generated for.

Comment 1

[Christian Eyrich]

Attachment: suggested patch

This patch will append a time zone string like "-0700" or "+0200" to the
timestamp.

The new switch withTZ is needed to prevend time zone string to be added to the
time in mail list and header information.

Doing a conversion from numeric "-0700" to PST or PDT would be possible too
using tables.

I'm aware of the possibility to just add %Z to the strftime format string in
FormatTMTime(). But I don't know
1. if this reliable (TZ information available in every system).
2. if this is possible the same way for the Windows and Mac version of this
function.

Comments welcome.

Comment 2

[[e-mail]]

Comment on attachment 131227 [details] [diff] [review]
suggested patch

I don't think changing intl is the right way to go, perhaps you could explode
the time in nsMsgCompose.cpp instead?

Comment 3

[Christian Eyrich]

Attachment: another variant of the patch

> I don't think changing intl is the right way to go, perhaps you could
> explode the time in nsMsgCompose.cpp instead?

FormatPRT() isn't the very right place, I agree. But I don't see a way to do
this patch without changing this function at least a little bit.

This is because the time zone information is only available in the explodedTime
struct and has to be exportet in some way.

Doing it the way the new patch does it, makes it impossible to convert from
numeric "-0700" to PST or PDT since the offsets aren't available in separate
form in nsMsgCompose.cpp (but could be enabled by adding another new parameter
to FormatPRTime()).

To this if a variable is named formattedDateString one would expect it holds
the full DateString (including TZ info). Not that one have to add it
afterwards.
Shouldn't this full string be available for every consumer that wants to get it
from FormatPRTime()?

Comment 4

[[e-mail]]

Ah, I see what you're getting at now... to do that you'll probably need to file
a bug on intl to get that changed first, sorry.

Comment 5

[Constantine A. Murenin]

I think this should not be the default behaviour. I am against setting it by
default, since it will confuse many users who just correspond with their fellow
citizens in their default time-zone. Possibly, one might add a user_pref for
showing the time-zone. 

One other option we might consider, is to use only date (with no time) for the
reply header, but it may also raise some concerns about time-zone... 

Comment 6

[uvr]

(In reply to comment #5)
> I think this should not be the default behaviour. I am against setting it by
> default, since it will confuse many users who just correspond with their 
> fellow citizens in their default time-zone.

Au contraire, I think adding timezone information makes time-related
confusion LESS probable.  Consider a case where sender John Smith is
sending a message at 14:59 EDT (US-Eastern) to three recipients in 
three different time zones: Jane Smith (located in US-EDT), John Doe
(located in US-Central) and Jane Doe (located in US-Pacific):

If timezone information is properly encoded in the attribution, then:

(1) When Jane Smith replies to the message, the attribution will contain
something like this:

        On 04/19/2004 14:59 EDT, John Smith wrote:

(2) When John Doe replies, the attribution will contain somethine like

        John Smith wrote at 04/19/2004 13:59 CDT:

(3) And when Jane Doe replies,

        John Smith at 04/19/2004 11:59 PDT:


Since the time zone is clearly marked in the attribution, there is very
little scope for confusion (and, indeed, if the sender and respondent
are in the same timezone, no confusion at all).

> Possibly, one might add a user_pref for showing the time-zone. 

Right.  And this is a good idea even if the suggested behavior is made
the default.
 
> One other option we might consider, is to use only date (with no time) for the
> reply header, but it may also raise some concerns about time-zone... 

I can suggest yet another option: Always use the sender's date only 
*with* the time zone, of course) in the attribution line.  If this
is done, then what this means for the various attribution lines in
the above John Smith-Jane Smith-John Doe-Jane Doe example is this:

(1) Jane Smith's reply:

On 04/19/2004 14:59 EDT, John Smith wrote:

(2) John Doe's reply:

John Smith wrote at 04/19/2004 14:59 EDT:

(3) Jane Doe's reply:

John Smith at 04/19/2004 14:59 EDT:

Absolutely no confusion here.

Infact, perhaps there should be a user_pref tunable that can be set 
to specify what should be in the attribution line: 0 -- no timezone,
1 -- sender's timezone, and 2 -- replier's timezone.

And, oh yes, I think using human intelligible strings like "PDT",
"EDT", "CET", "GMT" etc is preferable to using "-700", "+200" or
other such numeric strings.

Comment 7

[Constantine A. Murenin]

(In reply to comment #6)
> And, oh yes, I think using human intelligible strings like "PDT",
> "EDT", "CET", "GMT" etc is preferable to using "-700", "+200" or
> other such numeric strings.

It's not as easy as it sounds. These abbreviations are ambiguous (such as EST),
or they may be set to a wrong value on some end-user systems, or some systems
may not provide such values at all. Moreover, some time-zones do not have such
values, AFAIK. This is definitely not an easy solution. 

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, I'd prefer strings like -0700... because, say, EST does not tell me
anything, while with -0700 I can tell what the time means

Comment 9

[web]

Is there any chance to see this feature added to Thunderbird?

Comment 10

[Felix Miata]

When I look in the headers of a message I want to reply to, I see the following:

     Date: 19 Apr 2006 20:25:55 +0200

Why not just use that string as is except with "Date:" stripped away? It would be a whole lot more useful to preserve the complete timestamp of the sender's message. When I later look in my sent folder at the message I sent, wondering when I might expect a reply, it's a lot more helpful to know whether my response probably reached him during his local business hours or sleep hours than what my local time was when he sent me his message.

Comment 11

[David :Bienvenu]

Comment on attachment 131666 [details] [diff] [review]
another variant of the patch

are we allowed to put default parameters into an interface like this?

Comment 12

[Wayne Mery (:wsmwk)]

David, do you want to change the review request?

Comment 13

[David :Bienvenu]

Comment on attachment 131666 [details] [diff] [review]
another variant of the patch

switching review request for intl part of patch

Comment 14

[rsx11m]

I'm establishing a dependency to bug 107884, which should be considered "weak" though as the time-zone info certainly could be resolved with a stand-alone solution. My intention is mainly to keep track of all reply-header bugs which would benefit from the introduction of templates.

BTW: Looking at that patch, is this configurable? It appears to me that this would be hard-wired to always show the time zone, which may not be the choice
of all users, thus some configurability would be desirable if not yet present. Inclusion could be toggled with mailnews.display.original_date, for example, assuming that somebody displaying the full time stamps would also like to have them added in the reply headers.

Comment 15

[Ilyse Kazar]

(non-programmer, biz analyst here:) I strongly urge a new token (or field in the upcoming UI) for time zone, as separate from the date token. This would allow folks the choice as to whether they want time zone. Also feel strongly, after scanning above discussions, that +/- UTC zone be used. For folks who care to use time zones, it is indeed *less* confusing to use UTC. To expand on examples already given above: I host a small mailing list that includes folks from Belgium & Finland, across the US, and in Oz & NZ -- without inclusion of time zone in the reply_header string it looks like I'm replying to a NZ member's post that he wrote _tomorrow_. 

Thanks to all you programmer types, I love t-bird

Comment 17

[Przemyslaw Bialik]

@Christian Eyrich: any chances for updated ver of the patch (pref based) ?

Comment 18

[Kari Suomela]

This is not a "bug", but a functional flaw! If you guys still don't understand the basic function of reply header, look at Roundcubemail, AOL or something else that does it right!

Comment 19

[rsx11m]

(In reply to comment #17)
> @Christian Eyrich: any chances for updated ver of the patch (pref based) ?

Given that this patch is from 2003, it would be amazing if it still applies as is, so that likely would need some update either way.

There is some progress in bug 107884, with a patch pending on the introduction of templated reply headers. Currently, only one @D template for the localized date+time information is present, I could imagine to have another @Z template which would resolve to an original date+time+zone string as task for the bug here. OTOH, basing the date format on the pref would be independent from the template solution, with its @D implementation also using FormatPRTime().

Comment 20

[Christian Eyrich]

(In reply to comment #17)
> @Christian Eyrich: any chances for updated ver of the patch (pref based) ?

Don't know, at the moment I'm not even sure if that patch (wasn't actually only the core part without all the necessary changes to callers) could have possibly worked. PR_ExplodeTime() only outputs the offset of local time, not the senders time.
Since bug 386742 it's possible to get the original time zone info out of the parser, but it still needs to be preserved through the whole function chain until using it--and that's a long way.
But I'm somewhat out of routine with that code and don't have time unfortunatelly.

Comment 21

[Ilyse Kazar]

not in 3 :-( ... not complaining about you guys!! just really wishing for what seems to this non-progammer as the simple solution proposed in Comment 10. My reply attributions still use my own time zone which is just meaningless to my recipients (such as on a discussion list) if they wish to look up the original message.

Comment 22

[Ilyse Kazar]

and, FWIW, preferred format would definitely be "UTC" +/- NNNN. As opposed to "EST" "CDT" "CET" sort of abbreviations which are unlikely to be meaningful worldwide and might require Googling to figure out what the letters mean.

Comment 23

[Simon Montagu :smontagu]

Comment on attachment 131666 [details] [diff] [review]
another variant of the patch

The patch no longer applies (and the answer to the question in comment 11 is "no")

Comment 25

[Thomas Dwyer III]

This bug is 15 years old. I find it hard to believe that there isn't enough demand for timezone info to get this fixed. Do people just accept that it's ok to read through an email thread and not have any ability to determine exactly when each of the replies were sent? Are there so few people who communicate across timezones that it's just not a real problem?