Red Hat Bugzilla – Full Text Bug Listing
|Summary:||dhclient: incorrect time shown in *.leases file|
|Product:||[Fedora] Fedora||Reporter:||Mr-4 <mr.dash.four>|
|Component:||dhcp||Assignee:||Jiri Popelka <jpopelka>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-27 08:41:50 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Mr-4 2012-08-24 10:27:56 EDT
Description of problem: When a lease is obtained with dhclient, the corresponding dhclient-<interface>.leases file shows incorrect renew/rebind/expire times. All times shown take into account the current time zone, but do NOT account for daylight savings. In other words, if my time zone is GMT, but I am currently in a daylight savings time (i.e. BST - British Summer Time) all lease times are shown as GMT without the appropriate indication of what time zone these times are based on. Version-Release number of selected component (if applicable): dhclient 4.2, FC17 How reproducible: Always Steps to Reproduce: 1. Provided daylight savings are in effect, a current lease obtained from DHCP server should be enough, just cat dhclient-<interface>.leases file 2. 3. Actual results: Something like: [...] renew 2 2012/08/22 11:08:35; rebind 5 2012/08/25 14:38:32; expire 2012/08/25 20:08:56; The above times are calculated using the time zone, BUT without taking into account daylight savings, so using the example I've given above, assuming I am in BST, these times are GMT not BST (the current time zone I am in). Expected results: One of the following: 1. Use the *current* time zone (i.e. BST): renew 2 2012/08/22 12:08:35; rebind 5 2012/08/25 15:38:32; expire 2012/08/25 21:08:56; 2. Display full time with time zone settings, like: renew 2 2012/08/22 11:08:35 GMT; rebind 5 2012/08/25 14:38:32 GMT; expire 2012/08/25 20:08:56 GMT; Additional info:
Comment 1 Jiri Popelka 2012-08-24 11:10:11 EDT
dhclient.conf(5) says they are in UTC: " Dates are specified in one of two ways. The software will output times in these two formats depending on if the db-time-format configuration parameter has been set to default or local. db-time-format [ default | local ] ; The db-time-format option determines which of two output methods are used for printing times in leases files. The default format provides day-and-time in UTC, whereas local uses a seconds-since-epoch to store the time value, and helpfully places a local timezone time in a comment on the same line. " Does that change anything ? (/me has never enough understood this time zones stuff)
Comment 2 Mr-4 2012-08-24 20:44:33 EDT
Right, so the default format is in UTC (that's GMT+0 for you), which is correct, though there is no indication in the actual lease file that UTC is used. Maybe the lease file could be amended to show "UTC" instead of showing nothing and confusing the hell out of me and everyone else. I haven't tried the "local" format to see whether it accounts for proper daylight savings (will do that in a day or two) and will report back...
Comment 3 Mr-4 2012-08-26 09:01:36 EDT
I've had time to investigate this further and if the "local" format is used, the time in the comment field is correct, though the time zone (BST/GMT etc) is still missing - it shows something like "expire epoch 1346190295; # Tue Aug 28 22:44:55 2012". In conclusion, my suggestion would be for the correct time zone used to be added in both formats to avoid confusion - in the first format UTC is used, in the second the current time zone is used, though in both cases that is not clearly and immediately visible for someone who looks at that file. Including something like: expire 1 2012/08/28 21:44:55 UTC; # format 1 expire epoch 1346190295; # Tue Aug 28 22:44:55 2012 BST would present sufficient clarity, I think.
Comment 4 Jiri Popelka 2012-08-27 08:19:06 EDT
Created attachment 607190 [details] add time zone indication in the comment The change is easy and I'll send the patch upstream. I won't apply this in Fedora because as I understand it it's not a bug, just a feature request and we already have had enough patches deviating us from upstream.
Comment 5 Jiri Popelka 2012-08-27 08:41:50 EDT
Reported upstream as [ISC-Bugs #30780]. I'll post a reply here if there's any. Closing.