[tz] NetBSD and Android bionic APIs for tz values
Paul Eggert
eggert at cs.ucla.edu
Sun Aug 17 01:07:20 UTC 2014
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.
More information about the tz
mailing list