As a test, I made the following change which fixes both issues noted in my first post:

server:~$ diff althttpd.c althttpd.c.gmt 
--- althttpd.c
+++ althttpd.c.gmt
@@ -617,7 +617,7 @@
   struct tm *tm;
   static char zDate[100];
   tm = gmtime(&t);
-  strftime(zDate, sizeof(zDate), "%a, %d %b %Y %H:%M:%S %Z", tm);
+  strftime(zDate, sizeof(zDate), "%a, %d %b %Y %H:%M:%S GMT", tm);
   return zDate;
 }

I think the issue I'm seeing might be specific to musl libc. There is some discussion on the musl mailing list:

Link

about %Z but I don't understand it enough to know whether it's relevant. I'd already changed the timezone on my server to GMT as it was set to EST5EDT but althttpd was still returning headers as UTC.

I don't know anything about C, but this page on strftime says:

If a struct tm broken-down time structure is created or modified by gmtime() or gmtime_r(), it is unspecified whether the result of the %Z and %z conversion specifiers shall refer to UTC or the current local timezone, when strftime() is called with such a broken-down time structure.

And this page says this about gmtime:

The gmtime() function shall convert the time in seconds since the Epoch pointed to by timer into a broken-down time, expressed as Coordinated Universal Time (UTC).

So if the tm struct is always in UTC by virtue of being created by gmtime, and the result of %Z is unspecified, maybe replacing %Z with GMT isn't a terrible fix and should produce the correct/desired date string format on both glibc and musl based systems?

See also:

Rich Felker made this comment related to issues with %Z

I think if applications want to use zones other than the actual configured zone with strftime, they need to just do something like expand the %Z themselves with the string they want before calling strftime (note: this requires quoting any % in the name). I looked hard for a better solution that wouldn't crash valid applications, and couldn't find one at the time.

I think replacing %Z with GMT (as in the proposed patch above) is consistent with Rich's comment.

As a test, I made the following change which fixes both issues noted in my first post:

There were forum notification issues which caused your post to "fly under the radar," but i've made this fix in the tls-support branch, so it will get merged in whenever TLS does. (Or, if that branch doesn't get merged, or gets reimplemented in a different manner, we can cherry-pick this one-line fix.)

Great, thanks!

I believe the bug report I submitted for this should be closed.

I believe the bug report I submitted for this should be closed.

Done. Thank you for the reminder.

I just noticed this forum post:

Link

where %z vs %Z in the date format was discussed and this commit that made the change:

Link

As I mentioned above, I have a feeling that I'm seeing "UTC" vs "GMT" due to some difference between musl libc and glibc, or I'm missing a needed configuration somewhere at the OS level.

See this musl libc commit from 2017:

link

use the name UTC instead of GMT for UTC timezone notes by maintainer:

both C and POSIX use the term UTC to specify related functionality, despite POSIX defining it as something more like UT1 or historical (pre-UTC) GMT without leap seconds. neither specifies the associated string for %Z. old choice of "GMT" violated principle of least surprise for users and some applications/tests. use "UTC" instead.

I've cross posted all of this into an Alpine GitLab issue.

I will let it sit for another week or so to see if I get any additional feedback from the Alpine community and then submit a merge request for the Alpine package I maintain with the above patch.