It's the last two fields: "minutes west of GMT" and "daylight savings time", which didn't work on many OSs. On Mac OS X at least the minutes-west field was working correctly.
In version 10.1.3, to be released this weekend, both fields are working on: Mac OS X, Win32, SunOS and Ubuntu LINUX.
On FreeBSD and OpenBSD, at least on the machines, I have access to, 0 is returned for both fields, which may be caused by a missing time-zone configuration on this machines (e.g. FreeBSD on nfshost and OpenBSD on m64 (Ted Walther?!)
Machines need to be supplied with a time-zone database containing data for different geographical areas in the world. If this is missing, 0 is returned on both fields.
Lutz wrote:It's the last two fields: "minutes west of GMT" and "daylight savings time", which didn't work on many OSs. On Mac OS X at least the minutes-west field was working correctly.
In version 10.1.3, to be released this weekend, both fields are working on: Mac OS X, Win32, SunOS and Ubuntu LINUX.
On FreeBSD and OpenBSD, at least on the machines, I have access to, 0 is returned for both fields, which may be caused by a missing time-zone configuration on this machines (e.g. FreeBSD on nfshost and OpenBSD on m64 (Ted Walther?!)
Machines need to be supplied with a time-zone database containing data for different geographical areas in the world. If this is missing, 0 is returned on both fields.
I checked, timezone is properly configured (look at /etc/localtime, it is a link to a file in /usr/share/zoneinfo, which is a precompiled timezone file) Lots of info in the "zic" manpage, which stands for zone-info-compiler.
From the manpage of gettimeofday():
int gettimeofday(struct timeval *tv, struct timezone *tz);
The use of the timezone structure is obsolete; the tz argument should normally be specified as NULL. The tz_dsttime field has never been used under Linux; it has not been and will not be sup‐
ported by libc or glibc. Each and every occurrence of this field in the kernel source (other than the declaration) is a bug. Thus, the following is purely of historic interest.
May I recommend removing the last two fields from being returned by (now)?
For Mac OS X, UBUNTU Linux and SunOS I am using the GNU 'C' predefined variables 'int timezone' and 'int daylight'. But they don't work on FreeBSD and OpenBSD. For Mac OSX 'struct timezone' works too, but I wen with 'int timezone' and 'int daylight', as hey are more common.
We have it working now on Mac OS X, UBUNTU Linux, SunOS and Win32, so I will not drop it just because it doesn't work FreeBSD/OpenBSD ;-).
Ps: also found tm_gmtoff, and ltm->tm_isdst in 'struct tm' on BSDs, but they don't work either.
There must be a way to do this correctly on the BSD's, can somebody help? Specially FreeBSD is important as it is used so frequently at ISPs.
I just checked; the gmtime() and localtime() calls on OpenBSD 4.4 do return the correct data.
The tm_isdst field is an integer that indexes the tzname external variable, which contains the name of the timezone. Here is the output of a test program I wrote:
Here is the source of the test program, perhaps you will find it useful to run it on the other platforms as well, perhaps the Mac OSX and SunOS platforms.
the problem is somehow in how stuffIntegerList() is being called. Or maybe stuffIntegerList. Because the call to localtime() is returning the correct info. I verified this, after putting a call to tzset() in the main() function of newlisp. Then I put in some printf debugging, verified that the correct values are coming out of localtime(). Once they are put into stuffIntegerList, what comes out the other end of the newLISP prompt is 0 and 0.
Is it a problem that tm_gmtoff is negative, and not positive? the (UINT) cast looks possibly suspicious to me, although it didn't prevent printf() from accurately reporting the negative value when using the %d specifier.
I found the problem. gmtime() and localtime() (and a couple other functions) all put their result into the same underlying structure, and they return a pointer to it. So when you are calling gmtime(), Lutz, you are blasting over the values put there by localtime(). I'll have a patch ready for you shortly.
By the way, that behavior is documented in the BSD manpage and is allowed by POSIX.
Lutz, why are you using gettimeofday() instead of time()?
The fixed files newlisp.c and nl-filesys.c have been mailed to you. Using the (corrected) BSD method for everything except WIN_32 saves 9 lines of code, although 5 of those lines were comments. It shouldn't change the behavior for any platform.
On BSD, it is necessary to call tzset() before calling localtime(), and can't do any harm on other POSIX platforms.
I did another test. The call to tzset() may not even be necessary. I'll see make an even smaller patch; if that works on all platforms, then the bigger patch can be tossed. I just wanted to be extra safe.
[some time later...]
Although it seems to work without tzset(), tzset() should be called for another reason; using tzset() makes calls to localtime() utilize the environment variable TZ, allowing users to set the timezone on the fly in the traditional Unix method.
The new, less intrusive patch reduces the lines of code by 12, and I suspect I could cut out another couple lines of code; do AIX, TRU64, and OS2 all not support tzset(), gettimeofday(), localtime(), and gmtime()?
I got the code wrong; I hadn't looked closely at what value the offset was supposed to hold; tm_gmtoff holds seconds east of GMT, rather than the minutes west of GMT we are trying to return. Here is the fix: