reassign 380667 libc6 thanks CST is returned by tzname[0] so basically it is a broken value set for some timezones. A nice libc bug, not a proftpd one. There's surely some mergeable bug around for other programs ...
On Wed, Aug 02, 2006 at 10:21:25AM -0500, Jeff McClure wrote: > Quoting Francesco Paolo Lovergine <[EMAIL PROTECTED]>: > > > >uhm > > > >TZ=US/Central date > > > >gives me > > > >Wed Aug 2 09:43:49 CDT 2006 > > > >which is different from > > > >TZ=CST date > > > >Wed Aug 2 14:44:54 CST 2006 > > > >which indeed is the same as GMT. Would you please re-tzconfig with your TZ? > > I think we're getting close to the problem. Why is ProFTPD setting TZ > to "CST" instead of "US/Central"? I re-ran tzconfig and chose > US/Central. I confirmed (again) that both /etc/timezone and > /etc/localtime both point to the correct timezone (US/Central), but > when I log into ProFTPD with DefaultRoot set, I still get this: > > dbtserv.test.****.com (dbtserv.test.****.com[::ffff:10.100.51.2]) - set > TZ environment variable to 'CST' > > ProFTPD should be setting TZ equal to "US/Central" (or even "CST6CDT"), > not "CST". "CST" isn't even a valid time zone name. Since the time zone > name isn't valid, the system is dropping back to UTC. > > Just for fun, I sym-linked /usr/share/zoneinfo/CST to > /usr/share/zoneinfo/US/Central. That makes ProFTPD report the correct > time stamps, but that's a hack. ProFTPD should be setting TZ to the > correct timezone name. > PS: a possible work-aroud is avoiding to live in USA :) -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
