On Sat 23 Jul 2016 15:07, Eli Zaretskii <e...@gnu.org> writes: >> From: Andy Wingo <wi...@pobox.com> >> Cc: guile-devel@gnu.org >> Date: Sat, 23 Jul 2016 14:15:06 +0200 >> >> > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the >> > trick of appending "0" to the time-zone string, Windows runtime >> > doesn't support that. >> > +#ifndef __MINGW32__ >> > + /* Don't do this for MinGW: it only supports fixed-format >> > + TTTnnnDDD TZ specifications, and gets confused if a zero is >> > + appended. */ >> >> This patch disables the setzone() call entirely; seems to be the wrong >> thing, given that MinGW doesn't appear to have struct tm->tm_zone. What >> if we just disable appending the 0 to the time zone? > > I'm not sure I understand what you have in mind, but if you show a > patch and a simple test, I can run it here.
The current code: #if !defined (HAVE_STRUCT_TM_TM_ZONE) /* it seems the only way to tell non-GNU versions of strftime what zone to use (for the %Z format) is to set TZ in the environment. interrupts and thread switching must be deferred until TZ is restored. */ char **oldenv = NULL; SCM zone_spec = SCM_SIMPLE_VECTOR_REF (stime, 10); int have_zone = 0; if (scm_is_true (zone_spec) && scm_c_string_length (zone_spec) > 0) { /* it's not required that the TZ setting be correct, just that it has the right name. so try something like TZ=EST0. using only TZ=EST would be simpler but it doesn't work on some OSs, e.g., Solaris. */ SCM zone = scm_string_append (scm_list_2 (zone_spec, scm_from_locale_string ("0"))); have_zone = 1; SCM_CRITICAL_SECTION_START; oldenv = setzone (zone, SCM_ARG2, FUNC_NAME); } #endif You said that appending the 0 confuses MinGW, so you skip this section and the corresponding one after the nstrftime. But you're skipping the setzone too, so I don't see how the strftime tests would work. According to POSIX, our TZ value is valid: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html What is the MinGW restriction? You mention it in the comment but I don't understand the comment. Andy