On 2023-01-30 18:30, Owen Leibman via tz wrote:
Is there a setting that could/should be changed so that the digest is sent with the same header?
I hope so, though I don't manage the mailing list so I don't know the details. While we're on the subject, I see problems even with non-digests, as the old Pipermail 0.09 (Mailman edition) software used to create the TZDB mailing archive has problems with not just charsets, but also with format=flowed and with multipart emails. The Gzip'd Text downloads are munged too. I don't know how to file a trouble ticket for this sort of thing. Perhaps it's time for icann.org to upgrade to Mailman 3? Here are examples of the problems: * Wrong charset in archive: https://mm.icann.org/pipermail/tz/attachments/20230124/95019648/0001-Remove-... This was sent with the following header in the attachment: Content-Type: text/x-patch; charset=UTF-8; name="0001-Remove-UNUSUAL_OK_IPA.patch" Content-Disposition: attachment; filename="0001-Remove-UNUSUAL_OK_IPA.patch" Content-Transfer-Encoding: base64 Unfortunately, mm.icann.org loses the "x-patch" and "charset=UTF-8", as it replaces the Content-Type with "text/plain": $ wget -S https://mm.icann.org/pipermail/tz/attachments/20230124/95019648/0001-Remove-... 2>&1 | grep -i Content-Type: Content-Type: text/plain This causes most browsers to misdisplay the text: for example, Firefox displays "UNUSUAL_OK_LATIN_1 = ¡¢£¤¥¦§¨©«¬®¯°±²³´¶·¸¹»¼½¾¿×÷" instead of the correct "UNUSUAL_OK_LATIN_1 = ¡¢£¤¥¦§¨©«¬®¯°±²³´¶·¸¹»¼½¾¿×÷". This problem seems limited to attachments, as I do not see similar problems with <https://mm.icann.org/pipermail/tz/2019-June/028158.html> where the patch was sent directly not as an attachment, and where non-ASCII strings like "Phù Liễn" are correctly translated into HTML ASCII equivalents like "Phù Liễn". * format=flowed misdisplay: https://mm.icann.org/pipermail/tz/2023-January/032565.html This was sent with "Content-Type: text/plain; charset=UTF-8; format=flowed" but the HTML web page is rendered with fixed columns which means the display looks ragged on cell phones. On my cell phone it looks like the following, which is hard to read (it's not free verse!):
theory.html says, "If boundaries between regions are fluid, such as during a war or insurrection, do not bother to create a new timezone merely because of yet another boundary change." That seems to be the case here.
* Multipart email issues: https://mm.icann.org/pipermail/tz/2023-January/032575.html This shows up on my browser as:
Hello: Maybe it's wrong to calculate local time by using the latest version tzdada2022g when zoneid is "America/Ojinaga".
Thanks