Paul Eggert wrote:
> My plan has been to add them eventually to glibc, where they would be
> multithread-safe.
That would be nice, indeed!
Use cases that I can see:
- A server process that talks to several users in different locales and
time zones.
(We have locale_t for several years a
On 3/14/21 11:33 AM, Bruno Haible wrote:
A close term is "multithread-safe". The API could be implemented in a
multithread-safe way, but time_rz.c is not multithread-safe, due to the
function 'change_env'.
It is planned to provide a multithread-safe implementation at some point?
My plan has be
Paul Eggert wrote:
> > On NetBSD, tzalloc() is in libc, and tzalloc("\\") returns NULL.
> > On other platforms, tzalloc() comes from Gnulib, and tzalloc("\\") returns
> > non-NULL.
> >
> > Which behaviour is correct?
>
> Both. The set of su
On 3/14/21 4:53 AM, Bruno Haible wrote:
On NetBSD, tzalloc() is in libc, and tzalloc("\\") returns NULL.
On other platforms, tzalloc() comes from Gnulib, and tzalloc("\\") returns
non-NULL.
Which behaviour is correct?
Both. The set of supported TZ values is system-dependent.
> FAIL: test-parse-datetime
> =
>
> test-parse-datetime.c:434: assertion 'parse_datetime (&result, "TZ=\"\"",
> &now)' failed
> FAIL test-parse-datetime (exit status: 134)
The problem comes from the tzallo
* lib/time_rz.c (tzalloc): Fix comment.
---
ChangeLog | 5 +
lib/time_rz.c | 3 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a17429b..584df59 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2015-10-20 Paul Eggert
