[tz] NetBSD and Android bionic APIs for tz values

[enh]

On Sat, Aug 16, 2014 at 6:07 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> 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.

also, we've removed the non-standard functions from Android for LP64 :-)

> 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.