Bug 851636 - dhclient: incorrect time shown in *.leases file
dhclient: incorrect time shown in *.leases file
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jiri Popelka
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-08-24 10:27 EDT by Mr-4
Modified: 2012-08-27 08:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-27 08:41:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
add time zone indication in the comment (1.52 KB, patch)
2012-08-27 08:19 EDT, Jiri Popelka
no flags Details | Diff

  None (edit)
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:

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
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.

Note You need to log in before you can comment on or make changes to this bug.