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.
Created attachment 131227 [details] [diff] [review] 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 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?
Created attachment 131666 [details] [diff] [review] 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()?
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.
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...
(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.
(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.
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
Is there any chance to see this feature added to Thunderbird?
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 on attachment 131666 [details] [diff] [review] another variant of the patch are we allowed to put default parameters into an interface like this?
David, do you want to change the review request?
Comment on attachment 131666 [details] [diff] [review] another variant of the patch switching review request for intl part of patch
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.
(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
@Christian Eyrich: any chances for updated ver of the patch (pref based) ?
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!
(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().
(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.
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.
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 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")