The point (about which I was not all that clear really) is that using putenv is the wrong way (normally) to deal with time zones which the application wants to use (and to use a putenv solution, it has to know the zone - get it from somewhere.)
The better solution (which already exists) is to use parallel functions which are told which zone to use explicitly. That way you can operate in as many different zones as you like (well, up to the number that exist) in parallel, with no overhead at all (except the ram they use.)
Please forgive my innocence. It would be great if you provide function names. I assume you are pointing to function names in localtime.c? Do you mean the _rz functions? But then NETBSD_INSPIRED need to be defined (no problem, but may result in another porting issues for me on MS-Windows). ...
Because, if it were useful at all, that would defeat the point. The whole idea of yearistype was to be able to easily express relationships between years, and labels, that were unknown when the code was written. Anyone can add a line (or several) to a script to work out which years are "the year of the dog", but the code writers cannot, as they have no idea that this particular information is considered (by someone) to be useful.
I saw that Paul has started to make the -y option obsolete, thanks. This will solve another non-portable thing for MS-Windows. ...
The versions of the functions with the _z suffix (including _rz) which take an explicit zone (the result of tzalloc(zone_name) as a parameter should make things run much faster (and more reliably, especially if your applications are multi-threaded) than anything using putenv.
I will check and try to use the TZ code with as less modifications as possible.
You don't need that with the _z functions, they are *all* cached (all the ones that you are using anyway - and the application can decide whether it is better to retain a loaded zone, or save space and discard it, and then load it again later.)
Will check. Kees