--- a/ChangeLog	Mon Nov 06 23:20:23 2017 -0800
+++ b/ChangeLog	Sat Nov 11 15:14:26 2017 +0100
@@ -1,3 +1,8 @@
+2017-11-11  Bruno Haible  <bruno@clisp.org>
+
+	year2038: Tweak last patch.
+	* m4/year2038.m4 (gl_YEAR2038): Correct indentation.
+
 2017-11-06  Paul Eggert  <eggert@cs.ucla.edu>
 
 	year2038: be more insistent about 64-bit time_t

--- a/m4/year2038.m4	Mon Nov 06 23:20:23 2017 -0800
+++ b/m4/year2038.m4	Sat Nov 11 15:14:26 2017 +0100
@@ -20,51 +20,51 @@
 
 AC_DEFUN([gl_YEAR2038],
 [
-      dnl On many systems, time_t is already a 64-bit type.
-      dnl On those systems where time_t is still 32-bit, it requires kernel
-      dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
-      dnl is work in progress; see
-      dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
-      dnl
-      dnl On native Windows, the system include files define types __time32_t
-      dnl and __time64_t. By default, time_t is an alias of
-      dnl   - __time32_t on 32-bit mingw,
-      dnl   - __time64_t on 64-bit mingw and on MSVC (since MSVC 8).
-      dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an
-      dnl alias of __time64_t.
-      dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of
-      dnl __time32_t.
-      AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64],
-        [AC_COMPILE_IFELSE(
-           [AC_LANG_PROGRAM(
-              [[#include <time.h>
-                int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1];
-              ]],
-              [[]])],
-           [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
-        ])
-      if test $gl_cv_type_time_t_64 = no; then
-        AC_COMPILE_IFELSE(
-          [AC_LANG_SOURCE(
-             [[#ifdef _USE_32BIT_TIME_T
-                 int ok;
-               #else
-                 error fail
-               #endif
-             ]])],
-          [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
-          [# If TIME_T_32_BIT_OK is "no" (the default) and not cross-compiling
-           # and 'touch' works with a large timestamp, then evidently
-           # 64-bit time_t is desired and supported, so fail and ask
-           # the builder to fix the problem.  Otherwise, just warn the
-           # builder.
-           if test "${TIME_T_32_BIT_OK-no}" = no &&
-              test $cross_compiling = no &&
-              TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
-             rm -f conftest.time
-             AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
-           else
-             AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
-           fi])
-      fi
+  dnl On many systems, time_t is already a 64-bit type.
+  dnl On those systems where time_t is still 32-bit, it requires kernel
+  dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
+  dnl is work in progress; see
+  dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
+  dnl
+  dnl On native Windows, the system include files define types __time32_t
+  dnl and __time64_t. By default, time_t is an alias of
+  dnl   - __time32_t on 32-bit mingw,
+  dnl   - __time64_t on 64-bit mingw and on MSVC (since MSVC 8).
+  dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an
+  dnl alias of __time64_t.
+  dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of
+  dnl __time32_t.
+  AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64],
+    [AC_COMPILE_IFELSE(
+       [AC_LANG_PROGRAM(
+          [[#include <time.h>
+            int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1];
+          ]],
+          [[]])],
+       [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
+    ])
+  if test $gl_cv_type_time_t_64 = no; then
+    AC_COMPILE_IFELSE(
+      [AC_LANG_SOURCE(
+         [[#ifdef _USE_32BIT_TIME_T
+             int ok;
+           #else
+             error fail
+           #endif
+         ]])],
+      [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
+      [# If TIME_T_32_BIT_OK is "no" (the default) and not cross-compiling
+       # and 'touch' works with a large timestamp, then evidently 64-bit time_t
+       # is desired and supported, so fail and ask the builder to fix the
+       # problem.  Otherwise, just warn the builder.
+       if test "${TIME_T_32_BIT_OK-no}" = no \
+          && test $cross_compiling = no \
+          && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
+         rm -f conftest.time
+         AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
+       else
+         AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
+       fi
+      ])
+  fi
 ])