sender's local time is not customizable

[chrizilla]

Thanks so much for your great addon. The date formats could be improved though:

steps to reproduce

1. select extended reply header checkbox
2. in use long or customized format in date field select all radio boxes one by one

actual results

• use long or customized format in date field deselected: 14.6.2024, 14:48
• date in localized format: 14.6.2024, 14:48
• date in international format: Fri Jun 14 2024 14:48:45 GMT+0200 (Central European Summer Time)
• date in original format: Fri, 14 Jun 2024 08:48:47 -0400 (EDT)
• customized format (local): %D, %e %M %Y %H:%i UTC%: Fri, 14 Jun 2024 14:48 UTC+0200
• customized format (sender): %D, %e %M %Y %H:%i UTC%z: Fri, 14 Jun 2024 14:48 UTC+0200

problems:

• The only format which gives me the sender's local time is date in international format. But this format is not customizable unfortunately. So I cannot have a customizable local time of the sender.
• the last 2 lines result in the same datestring. This is probably not expected. I would exptect local to show my timezone and sender to show the sender's timezone.
• It would be nice to have a variable for short and long time zone name (like "Central European Summer Time" displayed above). Currently you can only display the timezone by utilizing the non-customizable date in international format. This should be customizable, too.

[Qeole]

This used to work, and seems to be a regression from b6bb418.

Before that commit, we would retrieve the sender's date from the Date: header (here). Then we had a specific function decodeCustomizedDateSender() that would extract the right date, time zone, and apply the custom formatting.

But after this commit, the add-on picks the sender's date from the Received: header field instead. This does not look correct, because looking at some emails received on a mailing list, this field seems to use the time zone from the mailing list server rather than the one from the sender. So we lose the information about the sender here already. And I think there's a second issue: when the add-on processes the date after that, it creates a new Date() object from the collected string (here). As far as I understand, this Date object stores no information about the time zone from the original string, it is just a time stamp that renders with toString() into the user's time zone. So we don't have any info left when trying to recover the time zone in decodeCustomizedDate().