When compiled with TM_EXTENSIONS, the strftime() function in
uClibc gives invalid timezone information. This has wide implication,
as most time functions on the system will display invalid timezone.
To visualise the bug, let's compare x86-glibc with arm-uClibc :
----- x86-blic --------------------------------
# date -u -R
Mon, 11 Jul 2005 17:32:20 +0000
# date -R
Mon, 11 Jul 2005 10:32:21 -0700
-----------------------------------------------
----- arm-uClibc --------------------------------------------
# ntpdate ntp3a
11 Jul 10:32:10 ntpdate[243]: step time server 15.X.X.X offset 1121103095.847544 sec
# date -u -R
Mon, 11 Jul 2005 17:32:26 GMT
# date -R
Mon, 11 Jul 2005 10:32:27 +0700
-------------------------------------------------------------
As you can see, the time is correct, which indicates that the
timezone is properly configured, however, the timezone is incorrect.
To understand the bug, consider this :
---- localtime() -------------------------------
#ifdef __UCLIBC_HAS_TM_EXTENSIONS__
result->tm_gmtoff = - tzi[dst].gmt_offset;
#endif /* __UCLIBC_HAS_TM_EXTENSIONS__ */
-------------------------------------------------
and :
---- strftime() ---------------------------------
#ifdef __UCLIBC_HAS_TM_EXTENSIONS__
#define RSP_GMT_OFFSET timeptr->tm_gmtoff
#else
#define RSP_GMT_OFFSET rsp->gmt_offset
#endif
*s = '+';
if ((tzo = -RSP_GMT_OFFSET) < 0) {
tzo = -tzo;
*s = '-';
}
-------------------------------------------------
Patch to fix the bug is attached (see attachement), and quite
trivial. Patch tested with uClibc-0.9.27 on ARM with BusyBox date. A
casual look at the latest CVS indicates that the patch is still needed
and would apply fine.
Note that I did not check if the same problem is present
elsewhere, however it looks like TM_EXTENSIONS are not used in other
places.
Have fun...
Jean
uClibc-strftime-timezone-2.patch [^] (642 bytes) 07-11-05 11:20 
