Bug 1299328

Summary: It's better to use current time from server instead of client to get resource age when using 'oc get/deploy/describe' etc
Product: OKD Reporter: Xingxing Xia <xxia>
Component: ocAssignee: Juan Vallejo <jvallejo>
Status: CLOSED NOTABUG QA Contact: Wei Sun <wsun>
Severity: low Docs Contact:
Priority: low    
Version: 3.xCC: aos-bugs, jvallejo, mmccomas, wjiang
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-08-01 18:02:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Xingxing Xia 2016-01-18 06:48:55 UTC
Description:
'oc get pod' will show pod 'AGE'. However, it gets 'AGE' according to current time from local host of oc client. When local time is earlier or later than server, and customer is unaware of this, 'AGE' will be wrong and confusing.
`oc deploy <dc name>` and `oc describe dc | grep 'Created:'` have similar problem.

Version-Release number of selected component (if applicable):
oc v1.1-766-g2eb4afc
kubernetes v1.1.0-origin-1107-g4c8e6f4

How reproducible:
Always

Steps to Reproduce:
Note: do all steps on local host instead of server host.
1. Check resource age:
$ oc get pod
NAME             READY     STATUS    RESTARTS   AGE
sample-1-cif39   1/1       Running   0          1m
2. Check local time
$ date
Fri Jan 15 10:44:00 CST 2016
3. Make local time 1 hour earlier
$ sudo date "9:44"
$ oc get pod
NAME             READY     STATUS    RESTARTS   AGE
sample-1-cif39   1/1       Running   0          <invalid>
4. Make local time 1 hour later
$ sudo date -s "11:44"
$ oc get pod
NAME             READY     STATUS    RESTARTS   AGE
sample-1-cif39   1/1       Running   0          1h
Actual results:
3 ~ 4:
When local time is earlier, 'AGE' is shown as '<invalid>'
When local time is later, 'AGE' is shown older than it should be.

Expected results:
It's better to return current server time to get resource 'AGE'. Otherwise, customer would be confused.

Comment 1 weiwei jiang 2016-01-18 10:16:14 UTC
Similar with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1270436

Comment 2 Juan Vallejo 2016-08-01 18:02:14 UTC
The "CreationTimestamp" for a pod is created by the server. 

The reason you are seeing different results when changing your client's time is because your client interprets the pod's timestamp according to what it thinks the current "date" is. 

A solution for getting around this would be to expose the server's Date through the api, and have the client parse the timestamp using that, however after talking with David Eads, this is not something that can be done.