On 2024-06-17 06:47, Bruno Haible wrote:
@item
This variable's contents are unreliable if you use a geographical
@env{TZ} setting like @code{TZ="America/Los_Angeles"}.
What do you mean by "unreliable"?
You'll get different results on different platforms, the tzname values
may not be
On 2024-06-17 08:32, Bruno Haible wrote:
NetBSD has a tzgetname() function: https://man.netbsd.org/tzset.3
tzgetname (tz, i) is equivalent to tzname[i].
This is the style of API I like better.
That API can't work in general. Some time zones have multiple
abbreviations for standard time. A cl
Paul Eggert wrote:
> >>> tzname is used in three places:
> >>> - time_rz,
> >>
> >> This should be fixed to use strftime instead.
> >
> > This seems wrong for two reasons:
> >
> >* time_rz is a small module, without textual I/O.
>
> Fair enough, and the changes I recently installed into
Hi Paul,
In tzname.texi you added:
@item
This variable's contents are unreliable if you use a geographical
@env{TZ} setting like @code{TZ="America/Los_Angeles"}.
What do you mean by "unreliable"? I tested the values for this TZ
and for my local one, and tzname is reasonable — the same valu
On 2024-06-06 17:03, Bruno Haible wrote:
Paul Eggert wrote:
tzname is used in three places:
- time_rz,
This should be fixed to use strftime instead.
This seems wrong for two reasons:
* time_rz is a small module, without textual I/O.
Fair enough, and the changes I recently installed
On 2024-06-06 14:30, Bruno Haible wrote:
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 forPOSIX:2024, but
POSIX:2024 (p. 2310-2311) does not warn against these 3 variables.
*https://man7.org
Paul Eggert wrote:
> > tzname is used in three places:
> >- time_rz,
>
> This should be fixed to use strftime instead.
This seems wrong for two reasons:
* time_rz is a small module, without textual I/O.
strftime is a large module, doing string formatting.
If time_rz depends on strf
On 6/6/24 14:30, Bruno Haible wrote:
tzname is used in three places:
- time_rz,
This should be fixed to use strftime instead.
- parse-datetime,
Likewise. (This usage of tzname is simply wrong, by the way, but it can
be compatibly wrong.)
- nstrftime, c-nstrftime.
These are
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
Some suggestions for improvement:
* 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 s
On MSVC, the nstrftime and c-nstrftime tests fail, because the %Z directive
produces an empty string instead of a time zone abbreviation.
The cause is that strftime.c contains code for two cases:
- HAVE_STRUCT_TM_TM_ZONE
- HAVE_TZNAME
but on MSVC both macros are undefined, since MSVC has '_tzn
11 matches
Mail list logo
