Parse the response Date header and expose in the Rate Limit information

[stephenc]

See https://issues.jenkins-ci.org/browse/JENKINS-47154

The rate limit information should expose the date of the rate limits by parsing the Date header rather than putting the consumer at the mercy of clock synchronization.

[samrocketman]

Some additional context:

$ curl -H "Authorization: token $GH_TOKEN" https://api.github.com/rate_limit -v 2>&1 | grep '^<'
< HTTP/1.1 200 OK
< Date: Wed, 27 Sep 2017 10:41:43 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 387
< Server: GitHub.com
< Status: 200 OK
< X-RateLimit-Limit: 5000
< X-RateLimit-Remaining: 4956
< X-RateLimit-Reset: 1506512184
< Cache-Control: no-cache
< X-OAuth-Scopes: admin:repo_hook, public_repo, user:email
< X-Accepted-OAuth-Scopes: 
< X-GitHub-Media-Type: github.v3; format=json
< Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
< Access-Control-Allow-Origin: *
< Content-Security-Policy: default-src 'none'
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-XSS-Protection: 1; mode=block
< X-Runtime-rack: 0.013775
< Vary: Accept-Encoding
< X-GitHub-Request-Id: BD9C:2781D:9236A57:AA76B23:59CB8067
<
$ date -d 'Wed, 27 Sep 2017 10:41:43 GMT' +%s
1506508903

Notice server response header: < Date: Wed, 27 Sep 2017 10:41:43 GMT. This is useful for time calculations of token rate limit reset. This would allow Jenkins plugins to depend on the time returned by GitHub.

Otherwise, depending on local system time has a risk of inaccuracy due to clock drift between the client and remote GitHub service.

[patrickleet]

I'm experiencing this now in a docker container.

I printed the time out, and it is the same as the server, though in UTC.

I noticed the timezone was GMT in jenkins systeminfo, so I restarted the container with an environment variable and successfully switched it to America/New York, but that did not resolve the issue either.

Any ideas for an immutable deployment. Going in and modifying something in the system might work, until the container got rescheduled..

[sgleske-ias]

Possibly related #327 ?