[tz] Charset for Digest Emails
eggert at cs.ucla.edu
Tue Jan 31 18:11:46 UTC 2023
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
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
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:
This was sent with the following header in the attachment:
Content-Type: text/x-patch; charset=UTF-8;
Content-Disposition: attachment; filename="0001-Remove-UNUSUAL_OK_IPA.patch"
Unfortunately, mm.icann.org loses the "x-patch" and "charset=UTF-8", as
it replaces the Content-Type with "text/plain":
$ wget -S
2>&1 | grep -i Content-Type:
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:
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:
This shows up on my browser as:
> Maybe it's wrong to calculate local time by using the latest version tzdada2022g when zoneid is "America/Ojinaga".
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mm.icann.org/pipermail/tz/attachments/20230131/a0d8ac2a/attachment.html>
and although I prefer plain text it'd be nice if there were a
more-intuitive way to switch back and forth between text and html
More information about the tz