I'm not entirely sure what the range check in libmailutils/datetime/utcoff.c is even trying to achieve - it's like it doesn't trust what gmtime() and locatime() are returning. Nevertheless, I have applied the following patch to my copy of the latest source:

*** libmailutils/datetime/utcoff.c.bak        2024-01-07 01:55:12.000000000 +1300
--- libmailutils/datetime/utcoff.c        2024-10-07 20:04:18.174110751 +1300
***************
*** 20,25 ****
--- 20,26 ----
  #include <time.h>

  #define SECS_PER_DAY 86400
+ #define MAXTZOFF 50400 /* 14 hours */
  #define TMSEC(t) (((t)->tm_hour * 60 + (t)->tm_min) * 60 + (t)->tm_sec)

  /* Returns the offset of our timezone from UTC, in seconds. */
***************
*** 32,38 ****
    int d = TMSEC (&ltm) - TMSEC (&gtm);
    if (d < 0 && -d > SECS_PER_DAY/2)
      d += SECS_PER_DAY;
!   else if (d > SECS_PER_DAY/2)
      d -= SECS_PER_DAY;
    return d;
  }
--- 33,39 ----
    int d = TMSEC (&ltm) - TMSEC (&gtm);
    if (d < 0 && -d > SECS_PER_DAY/2)
      d += SECS_PER_DAY;
!   else if (d > MAXTZOFF)
      d -= SECS_PER_DAY;
    return d;
  }

In short, I've allowed for offets of up to +14 hours, since +14 is the time zone for Kiribati, and I believe the highest likely timezone offset. Samoa and NZ daylight time are +13; Chatham Island standard time is 12:45 and daylight time +13:45 (yes, really). Again, I'm not sure what this code is trying to protect against so this may break something ... but it appears to solve my immediate problem.

I think there might still be an issue here - in particular with time zones above UTC+12. I'm currently in NZDT (UTC+13) and I've noticed that all the emails that are sent with the 'mail' command have the time zone in the 'Date' header set to -1100. I think the issue is with the 'else if (d > SECS_PER_DAY/2)' line since this will always be true for time zone offsets above UTC+12 and so it subtracts SECS_PER_DAY making my UTC+13 become UTC-11.

The introduction of message_add_date in GNU Mailutils 3.13, may lead to weirdness in the timezone offset in Date headers added when sending messages (eg "Date: Sat, 7 Aug 2021 23:00:01 +4400"). I believe the problem arises in mu_utc_offset() in libmailutils/datetime/utcoff.c when the day (or month or year) of the GMT date differs from that of the localtime date.

For example, consider a message being sent at 2005 EDT / 0005 UTC. In mu_utc_offset, TMSEC(&ltm) equals 72300 and TMSEC(&gtm) equals  300. Initially, d is assigned 72000. But since ltm.tm_mday does not equal gtm.tm_mday, the function adds a day's worth of seconds to it and returns 158400. And in turn, mu_c_streamftime() generates the timezone offset in the date header by converting that to hours (44 = 158400/(60*60)) and minutes (0 = (158400/60)%60).