From 20b988f88d15ce2fc9042663968ab6bc1a2c8159 Mon Sep 17 00:00:00 2001 From: Kevin Ryde Date: Mon, 31 Oct 2005 23:41:46 +0000 Subject: [PATCH] (Time): In strftime, note systems vary for %Z. --- doc/ref/posix.texi | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/ref/posix.texi b/doc/ref/posix.texi index 348e0893d..dce0d45af 100644 --- a/doc/ref/posix.texi +++ b/doc/ref/posix.texi @@ -1230,6 +1230,28 @@ formatting. If @code{setlocale} has been called (@pxref{Locales}), month and day names are from the current locale and in the locale character set. + +Note that @samp{%Z} might print the @code{tm:zone} in @var{tm} or it +might print just the current zone (@code{tzset} above). A GNU system +prints @code{tm:zone}, a strict C99 system like NetBSD prints the +current zone. Perhaps in the future Guile will try to get +@code{tm:zone} used always. +@c +@c The issue in the above is not just whether tm_zone exists in +@c struct tm, but whether libc feels it should read it. Being a +@c non-C99 field, a strict C99 program won't know to set it, quite +@c likely leaving garbage there. NetBSD, which has the field, +@c therefore takes the view that it mustn't read it. See the PR +@c about this at +@c +@c http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=21722 +@c +@c Uniformly making tm:zone used on all systems (all those which have +@c %Z at all of course) might be nice (either mung TZ and tzset, or +@c mung tzname[]). On the other hand it would make us do more than +@c C99 says, and we really don't want to get intimate with the gory +@c details of libc time funcs, no more than can be helped. +@c @end deffn @deffn {Scheme Procedure} strptime format string