[tz] NetBSD and Android bionic APIs for tz values
enh at google.com
Sun Aug 17 06:05:54 UTC 2014
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
> * 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
> * 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.
More information about the tz