On Tue, May 15, 2007 at 01:22:15PM +0200, Fathi Boudra wrote: > hi, > > This is definitely caused by a different behaviour of tzset(). The problem > occurs in Utility::setTimezone(). tzset should copy an unknown timezone into > tzname[0]. Looks like glibc tzset no longer does that. Not sure why Uli would > change that. Might be a bug. > > The patch submitted-date-and-unknown-tz.diff introduced in Sid glibc since > 2.5-1 causes taskjuggler FTBFS: > > * patches/any/submitted-date-and-unknown-tz.diff: fix date output in case of > an unknown timezone in $TZ, submitted upstream as #4028. > Closes: #55648, #119540, #269238. > > The submitted upstream bug report: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=4028 > > The proposed patch was rejected and upstream closed the bug as "resolved/ > wontfix": > > The existing behavior is as valid as any other. Any change will disrupt > > things, though. No change. > > Now, the question is what do we do ? Drop this patch like upstream does, will > re-open 3 other debian bug reports. > > Thanks to Pierre Habouzit, Aurelien Jarno and Chris Schlaeger for the > pointers.
Like I said to Fathi in private, here is what POSIX says about TZ:
DESCRIPTION
The tzset( ) function shall use the value of the environment
variable TZ to set time conversion
information used by ctime( ), localtime ( ), mktime( ), and
strftime( ). If TZ is absent from the
environment, implementation-defined default timezone information
shall be used.
The tzset( ) function shall set the external variable tzname as
follows:
tzname[0] = "std";
tzname[1] = "dst";
where std and dst are as described in the Base Definitions volume
of IEEE Std 1003.1-2001,
Chapter 8, Environment Variables.
XSI The tzset( ) function also shall set the external variable
daylight to 0 if Daylight Savings Time
conversions should never be applied for the timezone in use;
otherwise, non-zero. The external
variable timezone shall be set to the difference, in seconds,
between Coordinated Universal Time
(UTC) and local standard time.
I wont quote the whole chapter 8 of the Base Definitions as it's 2
pages long, but here is what is says:
either TZ is of the form :$foo (with the colon) and then tzset
behaviour is *implementation defined* or it's some very complex
numerical format describing the offsets and DST variations of the
timezone.
the GNU glibc choses to ignore wether the colon ':' is here or not,
but acting on a string remains implementation defined. Meaning that
another libc (dietlibc, uClibc, ...) may chose a completely different
behaviour, and would be correct.
The reason not to copy the TZ string in tzname[0] when the underlying
libc does not recognize it is that internally when TZ is not recognized,
the libc uses UTC as a timezone. If you copy your random string in
tzname you can confuse the admin that will see the name he put in TZ
appear in formats, though the application will remain in UTC, and that
fact is hidden, and can lead to big issues.
Hence in debian we choose not to hide that fact. Though, if you do :
TZ=FOO+0100 FOO will be copied to tzname[0] as we have all the
informations we need to "understand" $TZ.
So IMHO, that's a taskjuggler bug.
--
·O· Pierre Habouzit
··O [EMAIL PROTECTED]
OOO http://www.madism.org
pgpeqpk8XUusm.pgp
Description: PGP signature
