Show the sender's timezone in reply/forward intro lines (#7352)

[MiMoHo]

Implements #7352. Opened as a draft to agree on the exact format/behavior before finalizing (see the questions below).

What it does

The reply intro (On <date>, <sender> wrote:) and the forward header (Date: <date>) currently show the original message date converted to the quoting user's local time, with no timezone information — ambiguous for everyone else reading the reply. With this change, the date is formatted in the sender's original timezone with an explicit UTC offset, like Mutt and Claws Mail do (as suggested in the issue and welcomed there):

On 2020-04-28 10:35 +0900, Steve Jobs wrote:

The user's configured date_long format is still honored (localization included); only O (the offset) is appended.

Bug fixed along the way

@metalefty's in-house attempt in the issue failed because rcmail::format_date($string, $fmt, false) didn't behave as documented: for string input, the rcube_utils::strtotime() → new DateTime('@'.$ts) roundtrip discards the timezone contained in the input, so with $convert=false dates were rendered in UTC — neither the user's nor the original timezone. This PR switches the parsing to rcube_utils::anytodatetime() (which preserves the input's timezone and falls back to the same strtotime()), making $convert=false finally mean "keep the original timezone".

Impact on existing $convert=false callers (contact date fields in contacts/index.php, managesieve vacation dates): they now render dates in the timezone they were written in, instead of a UTC rendering that could be shifted by a day for servers with non-zero UTC offsets — a latent off-by-one fixed by this change. Behavior for $convert=true (all other callers) is unchanged: same instant, converted to the user's timezone as before. Invalid/zero dates (0000-00-00 00:00:00) still return an empty string (now guarded explicitly).

Questions for maintainers (why this is a draft)

1. Is date_long . ' O' the right format (e.g. 2020-04-28 10:35 +0900), or would you prefer a dedicated config option (e.g. reply_date_format) so admins/users can control it?
2. Should this stay unconditional (like Mutt), or be opt-in?
3. The issue's reporter also wished for timezone display in the message view — that's a separate UI/config topic; users can already add O/e to their date_format settings. I'd keep it out of scope here.

Testing

• New unit test ComposeTest::test_get_reply_header() asserting the exact intro line for a +0900 message date.
• RcmailTest::test_format_date() extended: string input with $convert=false preserves the input offset, $convert=true converts as before; empty/invalid/zero-date inputs return ''.
• Full PHPUnit suite passes (PHP 8.5.8; single pre-existing local failure of RcubeTest::test_exec, BSD vs GNU date on macOS, unrelated).
• php-cs-fixer and phpstan clean on all changed files.

This contribution was prepared with AI assistance (Claude Code); analysis and test results were verified as described.

🤖 Generated with Claude Code