+++ This bug was initially created as a clone of Bug #683680 +++ Description of problem: Querying hrSystemDate returns a value for the time zone which is negative when it should be positive and positive when it should be negative. Version-Release number of selected component (if applicable): net-snmp-5.5-21.fc14 How reproducible: 100% Steps to Reproduce: 1. Configure net-snmp to allow public queries for hrSystemDate by adding view systemview included .1.3.6.1.2.1.25.1.2 to /etc/snmp/snmpd.conf. 2. Restart snmpd ("service snmpd restart") 3. Run snmpwalk -c public -v1 localhost hrSystemDate; date '+%F,%T,%z' Actual results: # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z' HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,+8:0 End of MIB 2011-03-09,16:37:47,-0800 (Note that the sign on the timezone of snmpwalk and date differ) Expected results: # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z' HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,-8:0 End of MIB 2011-03-09,16:37:47,-0800 (Note that the sign on the timezone of snmpwalk and date agree) Additional info: * Also reported upstream: http://sourceforge.net/tracker/index.php?func=detail&aid=3178389&group_id=12694&atid=112694 * Patch forthcoming. --- Additional comment from bmason on 2011-03-10 13:29:41 EST --- Created attachment 483534 [details] Proposed Patch The attached patch resolves the issue in my testing. The problem appears to be with the following bit of code in date_n_time() in snmplib/snmp-tc.c: 167 #ifdef HAVE_STRUCT_TM_TM_GMTOFF 168 const int tzoffset = tm_p->tm_gmtoff; 169 #else 170 const int tzoffset = timezone; 171 #endif The problem is that, according to the comments in /usr/include/time.h, tm_gmtoff is "Seconds east of UTC" whereas timezone appears to be "Seconds west of UTC." in RHEL 6, HAVE_STRUCT_TM_TM_GMTOFF is true, so gm_gmtoff is used to generate the timezone information. In RHEL 5, this value (actually STRUCT_TM_HAS_TM_GMTOFF) is false, so timezone is used and the value of tzoffset is correct. I believe the fix is to simply negate the value of tm_p->tm_gmtoff before assigning it to tzoffset. --- Additional comment from bmason on 2011-03-10 13:49:24 EST --- As it turns out, upstream has the same solution. And we both came up with that solution within hours of each other. :) http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/snmplib/snmp-tc.c?r1=20006&r2=20104
I believe the bug is fixed in net-snmp-5.7, which has been in Rawhide (and F16) for some time.