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 supported TZ values is system-dependent.

OK, then we need to
  - conditionally disable the respective parts of the parse-datetime test
    (done through patch 1 below),
  - update the documentation of tzalloc to clarify that it may return NULL
    for arguments that the implementation considers as invalid.
    (done through patch 2 below).

I also took the opportunity to move the documentation of the 'time_rz'
module from the module description to the .h file. Why?
  - Because the usual places where people look for reference documentation are
    the manual and the .h files. They don't look in the module description.
  - Because the reference documentation refers to arguments of these functions,
    by name. One cannot understand the documentation if the function
    declarations are far away.

Another thing: The module summary reads

   Reentrant time zone functions: localtime_rz, mktime_z, etc.

What does the word "reentrant" mean here? Since the functions localtime_rz,
mktime_z don't invoke themselves recursively with a different time zone
argument, nor do they take function pointer parameters (callback), I think
"reentrant" means nothing here.

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?

Bruno