In thinking about the problem with MS-Windows file name syntax, I would like to avoid complicating tzcode in areas where the complication isn't really needed. The zic man page already says that portable time zone names should not use constructs like leading "C:" and/or backslash. It shouldn't be tzcode's job to worry about the limitations of DOS file names, any more than it's tzcode's job to worry about file name restrictions imposed by VMS, z/OS, ISO 9660, etc. ... So, instead of adding a bunch of code to deal with backslashes and drive letters, I'd like to remove the couple of stray lines of code that attempt to deal with this issue and which (obviously) do not suffice to solve the problem.
I agree with you regarding slashes, because (most) Windows API functions allow to use UNIX-style slashes. But support for drive letters is a must have on Windows, as the root (in UNIX terms) of a process is relative to a drive. If a process was started from drive D:, Then '/' points to D:, but if the zonefiles exist on drive C:, they can't be opened. I don't know how to work around this. To fix this, the TZ library needs support for Windows drive-letters or if anyone else can provide suggestions for another approach.
* I think Robert Elz covered the putenv issue fairly well: that is, the problem has already been solved, in a different way.
I've checked latest version, but do not understand how it is fixed. Maybe I missed something in the localtime.c code? I'm afraid I don't fully understand why Robert Elz solution is a fix. Please keep in mind that I'm not living only In the GNU/Linux world. I've to work with HPUX, Solaris, AIX, Windows as well (= not (!) using GNU libs).
If MS-Windows does not have shell scripts, then calling 'system' always fails, right? That should be good enough. (While we're on the topic, I wouldn't mind deprecating the 'y' option on all platforms, as it hasn't been needed for years and it has security implications.) Yes, but yearistype is always needed, and if nobody changes the shell script, why not keep this code into C? It is *much* faster than create a child process to execute the shell script. Moving away from shell scripts may also solves security implications?
As far as I can tell, this merely improves zic's performance a bit on platforms lacking the symlink system call. I wouldn't worry about this. It's better to keep the code simpler and easier to maintain, than to worry about barely-significant tuning of a rarely-used and plenty-fast program, a tuning that helps only nonstandard platforms.
Our own software heavily relies on switching time zones, so any improvement is welcome. Also, that's why we have improved mkime (with the time_succesive() code), as the current approach is pretty inefficient. We are considering to make a LRU cache, to cache the last 2 time zonefiles loaded. Regards, Kees