patch for scli-0.2.8: converting timestamps to strings
There is a small bug in scli-0.2.8 in the code for converting time ticks relative to the current time into local time plus GMT offset.
The problem is that with
tm->tm_isdst = 0; mktime(tm);
the time struct in tm is modified by mktime, so that it represents the time with DST and tm_isdst is set, if DST is in effect at that time. This is done at least by glibc-2 and correct according to ISO 9899. That leads to the time in tm to be one hour ahead if DST is in effect:
isnogud:src$ echo show system info | scli localhost Name: isnogud Address: localhost:161 Description: Linux isnogud 2.4.18-ut #41 Wed Apr 3 23:28:01 CEST 2002 i686 Contact: Urs Thuermann urs@isnogud.escape.de Location: D-38106 Braunschweig, Germany Vendor: UCD-SNMP http://ucd-snmp.ucdavis.edu/ Current Time: 2002-05-02 08:55:58 +02:00 Agent Boot Time: 2002-05-02 09:04:37 +02:00 <--- [*] System Boot Time: 2002-04-24 21:51:10 +02:00 <--- [*] System Boot Args: auto BOOT_IMAGE=linux-2.4.18 ro root=100 ROOT=/dev/vg0/root Users: 3 Processes: 86 Memory: 250M Interfaces: 8 isnogud:src$ TZ= ls -l /var/log/boot.msg -rw-r--r-- 1 root root 4335 Apr 24 18:51 /var/log/boot.msg ^^^^^ isnogud:src$ ps xau|grep ^root.*snmp root 31871 0.1 0.8 3092 2068 ? S 08:04 0:04 /usr/sbin/snmpd ^^^^^
[*] Theses time are one hour ahead. The same problem can be seen with other times, too.
The appended patch solves the problem.
urs
diff -ru scli-0.2.8/scli/fmt.c scli/scli/fmt.c --- scli-0.2.8/scli/fmt.c 2002-03-27 14:41:27.000000000 +0100 +++ scli/scli/fmt.c 2002-05-02 08:03:22.000000000 +0200 @@ -81,7 +81,7 @@ { static char buffer[80]; time_t now, gmt; - struct tm *tm; + struct tm *tm, now_tm; int gmt_offset;
now = time(NULL); @@ -99,13 +99,14 @@ gmt = mktime(tm);
tm = localtime(&now); + now_tm = *tm; tm->tm_isdst = 0; gmt_offset = mktime(tm) - gmt;
g_snprintf(buffer, sizeof(buffer), "%04d-%02d-%02d %02d:%02d:%02d %c%02d:%02d", - tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday, - tm->tm_hour, tm->tm_min, tm->tm_sec, + now_tm.tm_year + 1900, now_tm.tm_mon + 1, now_tm.tm_mday, + now_tm.tm_hour, now_tm.tm_min, now_tm.tm_sec, gmt_offset >= 0 ? '+' : '-', (int) ABS(gmt_offset) / 3600, (int) (ABS(gmt_offset) / 60) % 60);
Urs Thuermann writes:
Urs> There is a small bug in scli-0.2.8 in the code for converting Urs> time ticks relative to the current time into local time plus GMT Urs> offset.
[...]
Thanks Urs for the nice explanation and the patch. I just checked it into the CVS. With that patch in place, I am starting to wonder whether scli should really display DateAndTime values as reported by the agent or whether it should always convert into scli's local time zone. Consider the following example:
$ TZ=UTC ./scli -c "show system info" xxxx | grep Time Current Time: 2002-05-02 12:04:05 +02:00 Agent Boot Time: 2002-04-20 15:29:15 +00:00 System Boot Time: 2002-01-22 09:41:39 +00:00
Obviously, the boot time stamps honor the local time zone (since they were computed by scli from TimeTicks values) while the current time is displayed in the time zone of the device. Perhaps it would be more intuitive to get all time values in the local time zone - allowing people to use TZ to control the actual time zone for all time stamps.
Comments?
/js
Hi!
Juergen> [...] Consider the following example:
Juergen> $ TZ=UTC ./scli -c "show system info" xxxx | grep Time Juergen> Current Time: 2002-05-02 12:04:05 +02:00 Juergen> Agent Boot Time: 2002-04-20 15:29:15 +00:00 Juergen> System Boot Time: 2002-01-22 09:41:39 +00:00
Juergen> Obviously, the boot time stamps honor the local time zone (since they Juergen> were computed by scli from TimeTicks values) while the current time is Juergen> displayed in the time zone of the device. Perhaps it would be more Juergen> intuitive to get all time values in the local time zone - allowing Juergen> people to use TZ to control the actual time zone for all time stamps.
Juergen> Comments?
In general, I agree. ;-) But I could also imagine situations, where the agent's timezone could be useful, e.g. when you setup a Schedule-MIB entry to launch a backup process at midnight (agent time). I suggest three steps:
(1) Do print all time stamps according to a common timezone, preferably the scli's local timezone (by default). (2) Append a clearifying string to printed timestamps, e.g.: Current Time: 2002-05-02 12:04:05 +00:00 (console time) (3) Introduce a configurable variable (set scli timezone <console|agent>) and print timestamps accordingly, e.g.: Current Time: 2002-05-02 12:04:05 +02:00 (agent time)
-frank
participants (3)
-
Frank Strauss
-
Juergen Schoenwaelder
-
Urs Thuermann