[uClibc] mktime and TZ env variable

David Muse dmuse at 4accesscommunications.com
Fri Oct 31 17:02:09 UTC 2003


Hello all,

I'm currently having a problem with mktime and the TZ environment variable.  I built a uClibc cross-compiler toolchain for arm, configured with the following timezone-related options (the defaults):

UCLIBC_HAS_TM_EXTENSIONS=y
UCLIBC_HAS_TZ_CACHING=y
UCLIBC_HAS_TZ_FILE=y
UCLIBC_HAS_TZ_FILE_READ_MANY=y
UCLIBC_TZ_FILE_PATH="/etc/TZ"

I have an application that is trying to set the system time.  But after setting the time, no matter what, the busybox "date" command always shows the timezone to be UTC.  When I rebuild everything with a glibc-based cross-compiler toolchain, I don't have this problem.  Here is some code that exposes the problem:

testdate.C:

#include <time.h>
#include <stdio.h>
#include <stdlib.h>

main() {

	struct tm	*tms=new struct tm;
	tms->tm_sec=0;
	tms->tm_min=45;
	tms->tm_hour=10;
	tms->tm_mday=31;
	tms->tm_mon=10-1;
	tms->tm_year=2003-1900;

	setenv("TZ","EST",1);

	mktime(tms);

	printf("%d/%02d/%d %02d:%02d:%02d %s\n",
		tms->tm_mon+1,tms->tm_mday,tms->tm_year+1900,
		tms->tm_hour,tms->tm_min,tms->tm_sec,
		tms->tm_zone);

	delete tms;
}

This can be compiled with arm-uclibc-g++ -o testdate testdate.C

Oddly, when using uClibc if I use a static struct tm, it segfaults.  In effect, if I replace "struct tm *tms=new struct tms;" with "struct tm tms;" and then use "tms.tm_*" instead of "tms->tm_*" and use "mktime(&tms);" instead of "mktime(tms);" and don't "delete tms;", then it segfaults, but it works using glibc.

The output of this program on a glibc-based system is:

10/31/2003 10:45:00 EST

on a uClibc-based system it's:

10/31/2003 10:45:00 .

The timezone is given as a period.  I assume this is just an artifact of it being unset or something.

So, what am I doing wrong, if anything?

I'm looking at the uClibc code right now and rebuilding it with some debug to narrow down the issue further, but hopefully someone will know the answer and get back to me before that :)

Thanks,

David Muse
dmuse at 4accesscommunications.com



More information about the uClibc mailing list