[tz] NetBSD and Android bionic APIs for tz values

[Paul Eggert]

In thinking about what to do with possibly modifying the tz code to have 
time zone values as part of the API, I reviewed the NetBSD and Android 
bionic APIs in this area.

Here are my thoughts on the NetBSD vs Android bionic interface:

* Android bionic has a function mktime_tz that works like NetBSD's 
tzalloc + mktime_z, and which uses a cache to work around the resulting 
performance problems.  Android's API is easier to use for mktime but the 
NetBSD approach feels like a better match for the rest of the API, as 
it's more flexible and efficient.  Also, NetBSD has localtime_rz but 
Android lacks this functionality.  So between the two the NetBSD style 
seems like a better way to go.

However, here are some problems I found with the NetBSD API.  They're 
relatively minor but do need fixing.

* The NetBSD API's declarations confused about 'const'.  Several 
functions take arguments of type 'const timezone_t' but the const does 
not have the intended meaning: it declares the argument to be a constant 
pointer to non-constant data, which means the 'const' is irrelevant to 
the caller and is ignored by the API.  The simplest fix is to remove the 
'const's from the API's declarations.

* The arguments of localtime_rz and mktime_z should all be 
restrict-qualified, for the same reason that localtime_r's arguments are 
restrict-qualified.

* ctime and ctime_r have been deprecated by POSIX due to their security 
issues, and ctime_rz has the same issues, so I suggest deprecating 
ctime_rz in NetBSD, and the tz code should not support it.  Callers can 
use strftime instead.

* tzgetname doesn't work for time zones that have three or more 
abbreviations.  Plus, tzgetname is redundant since callers can instead 
use localtime_rz + strftime %Z, an approach that works even with three 
or more abbreviations.  Again, I suggest deprecating tzgetname in 
NetBSD, and the tz code should not support it.

I don't know whether these NetBSD issues are something Christos can fix 
directly or whether we need to file NetBSD bug reports or whatever.