Paul Eggert wrote: > * Don't make tzname a module, as this mistakenly suggests that tzname is > useful. Instead, leave tzname's implementation as internal detail of the > nstrftime and c-nstrftime modules. This should be easy. > > * Since tzname should be an internal detail, Gnulib can still use > AC_STRUCT_TIMEZONE and have MS-specific code for _tzname that is private > to nstrftime and c-nstrftime. This would be a less-intrusive change to > Gnulib. This should be relatively easy too.
tzname is used in three places: - time_rz, - parse-datetime, - nstrftime, c-nstrftime. If it had been in use by only one module (and if it wasn't specified by POSIX:2018), I would of course have considered to make it an internal detail. > At the very least we need to document that tzname has significant > problems, which I did by installing the attached. OK. But how about the Linux man-pages? * https://man7.org/linux/man-pages/man3/tzset.3p.html is derived from POSIX and will be updated for POSIX:2024, but POSIX:2024 (p. 2310-2311) does not warn against these 3 variables. * https://man7.org/linux/man-pages/man3/tzset.3.html does not warn against these 3 variables either. * https://man7.org/linux/man-pages/man3/tm.3type.html says that "The tm_gmtoff field provides an alternative" for systems without the 'timezone' variable. (Yes! Not the other way around.) Will you also write to linux-...@vger.kernel.org ? > * Support tm_zone and tm_gmtoff instead. They're in most useful systems > nowadays, and are standardized in POSIX.1-2024. This would be > considerably harder. I agree that it will be hard to implement this part of POSIX:2024, because (as we have seen with 'struct stat') overriding a struct is hairy. The platforms that have tm_zone and tm_gmtoff: glibc, musl, macOS, *BSD, Android. The platforms that don't have them: AIX, Solaris, Cygwin, mingw, MSVC. Is tm_zone well-designed at all? In https://man7.org/linux/man-pages/man3/tm.3type.html I read: "tm_zone points to static storage and may be overridden on subsequent calls to localtime(3) and similar functions (however, this never happens under glibc)." Bruno
