[tz] proposed changes for Win32 and a improved mktime() algorithm
Kees.Dekker at infor.com
Wed May 24 15:14:58 UTC 2017
>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.
More information about the tz