[tz] proposed changes for Win32 and a improved mktime() algorithm

[Kees Dekker]

>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