Open Bug 360266 Opened 13 years ago Updated 11 years ago

(option to) use ISO8601 for mailnews.reply_header_ondate %s


(MailNews Core :: Internationalization, enhancement)

Not set


(Not tracked)



(Reporter: mrmazda, Assigned: ch.ey)



(1 file, 1 obsolete file)

Locale is good for most mailnews contexts, but in a mail or news reply message context neither Thunderbird nor SeaMonkey should be converting from the quoted author's locale to something else that may be ambiguous or clearly erroneous to the recipient(s). More email and news posts cross timezones than not. The quoted date and time should be unambiguous regardless of the recipient's or author's locale or timezone. The only sensible way to do that is with a complete and fully ISO 8601 compliant date/time string. It should either be in UTC time, or include an explicit TZ correction.
I'm not sure if it should fix set to ISO 8601. But it should a) be available and b) best be default.

There's the pref mailnews.reply_header_locale which controls the format of date/time in the reply header (though this doesn't work on Linux because of bug 211004).
The locale en-DK is well known on Linux to result in ISO 8601 formatted date. This isn't available on Windows, here I know sv-SE to work with the same result. It does on Linux also, but one has to install that locale first.
I don't know about OS/2 or Mac.
Just to be clear, here you see a reply to a post that originated when it was June 2 at the place it originated when its creator created it. The sender UA's date string is unambiguous in the SM message view pane, but SM in the reply window, as in the header pane, has converted it to my time zone, changing the date sent to June 1 in the process. It shouldn't do that, but instead preserve the original message's full date string where it is quoted in the reply message.
Ah yes, I only refered to the formatting of the date itself, not what it displays.
So getting the timezone. I'm a bit surprised about what your screenshot shows. Has the text been modified by you? I can't make the date string in the attribution line contain any timezone information.
And that the date string in your message pane is in the senders timezone including that information is also not normal. I guess you set mailnews.display.original_date to true, yes?

I agree with you in that date strings, or at least those published on the net, should be unambiguous. That means these dates should contain a timezone information.
If we're outputing an interpreted and reformated string (as now), the date can be in your timezone or in UTC.
If we'd use the same trick as I did when introducing original_date in bug 118899 it would be in the original timezone. Since it's a verbatim copy from the mail header, this would also affect the format, i.e. that specified in RFC 822 -- ISO 8601 format would be impossible.
That's also the drawback I don't like. It was acceptable for the display in the message pane, but not for usage in mails, I think.
(In reply to comment #3)
> Has the text been modified by you?... I guess you set
> mailnews.display.original_date to true, yes?

Text of what modified, some prefs? Here are a few I have that are non-default:
mailnews.display.original_date true
mailnews.quotingPrefs.version 1
mailnews.reply_header_authorwrote %s apparently typed
mailnews.reply_header_colon :\n
mailnews.reply_header_locale en-DK
mailnews.reply_header_ondate On 20%s (GMT -0400)
mailnews.reply_header_type 2
Note that I have mailnews.reply_header_ondate set as I have to minimize the effort involved to do manually what I expect a competent user agent to do for me. When I don't forget, when I reply to a message I edit GMT -0400 to read as the original message read.
Ah ok, adding your local timezone to reply_header_ondate was what I meant.

I fear your request isn't possible to satisfy. As far as I can see we can't output ISO 8601 date with timezone and implementing it requires either an ugly hack or huge code duplication which I fear will not get reviewed both.
But I guess I'll give it a try next week.
If this truly isn't practical to implement, the complete date extracted from the original message would be much better than what happens now.
I wasn't precise in my last comment. It's (currently) not possible to output ISO 8601 date with timezone information _in the original authors timezone_. But it's possible when outputting it in local timezone as it's up to now - though that's not the perfect solution.
This patch makes two changes.
1. ISO 8601:1998 format is default date/time format. It's used when mailnews.reply_header_locale is not set.
2. A timezone information like +0200 is added to the date/time string.

The call to FormatPRTime() was explicitly replaced by its content in order to have access to the PRExplodedTime struct. That's a little code duplication but saves us from having two calls to PR_ExplodeTime().

Note: I was only able to test on Linux, i.e. nsDateTimeFormatUnix. I can only hope it will work on other OS, please test.
Assignee: smontagu → ch.ey
Attachment #270739 - Flags: review?(smontagu)
Attachment #270739 - Attachment is obsolete: true
Attachment #270739 - Flags: review?(smontagu)
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.