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