Christos Zoulas wrote:
If we are going to standardize those two, I think that tm_zone should become an array instead of a pointer, or at least the "char *" pointer lifetime and ownership should be defined.
This is all doable. An API standard could allow tm_zone to be either a char array or a char const * pointer, with applications not supposed to care. This would allow existing implementations and would allow the alternative implementation that you're thinking of. If tm_zone is a pointer, its lifetime would be that of the corresponding timezone_t object (for the new API with localtime_rz etc.) for until the next call to tzset (either explicit or implied) with a different TZ value (for the traditional API with localtime_r etc.).
if we are changing tm_zone, then tm_gmtoff should be an int not a long. Does anyone remember why it was chosen to be a long? 16 bit integers on pdp 11? Does "struct tm" go that far back?
When tm_gmtoff was designed, 'long' was the only portable type that was guaranteed to be wide enough to hold practical UT offsets. To standardize tm_gmtoff we should probably invent a typedef for it, presumably 'gmtoff_t'. That way, new implementations could use (say) 'int_least32_t' for it if they wanted to.