Closed mpoegel closed 9 years ago
Does github not have some way to find the timezone of the commit? That is unfortunate. On Nov 23, 2014 10:41 PM, "Matt Poegel" notifications@github.com wrote:
We cannot just grab the timestamp from the metadata returned from the github api because that timestamp is dependent of the timezone in which it was committed.
We could use the server timestamp at the moment the commit message was fetched but the drawback here is that old commit messages (up to 30) from a new repo will all be marked with same (current) time.
— Reply to this email directly or view it on GitHub https://github.com/mpoegel/HackRPI-Status-Board/issues/8.
The time is given in UTC.
Maybe I'll change my system clock and push some test commits to see how the time in the API response changes.
It might be a general git shortcoming.
On Mon, Nov 24, 2014 at 2:40 PM, Matt Poegel notifications@github.com wrote:
The time is given in UTC.
Maybe I'll change my system clock and push some test commits to see how the time in the API response changes.
— Reply to this email directly or view it on GitHub https://github.com/mpoegel/HackRPI-Status-Board/issues/8#issuecomment-64251013 .
My requests to the Github API return this: "date": "2014-12-27T10:58:23Z" (no timezone), but the API docs say it should return something like this: "date": "2014-02-27T15:05:06+01:00" (notice timezone). Ugh.
Meanwhile, I think the simplest work-around would be to add a check the time of each commit as it is received and if it is in the future (compared to the server time) then assign it the current server time. This will prevent old commits from appearing most recent.
EDIT: From recent observations of Github's user commit timeline, it would seem that the system is quite imperfect and often assigns incorrect dates in the future. They seem to be eventually corrected, but once the commit is in our DB, it is not checked again to see if its date has changed. Thus, the above workaround is definitely the safest fix.
We cannot just grab the timestamp from the metadata returned from the github api because that timestamp is dependent of the timezone in which it was committed.
We could use the server timestamp at the moment the commit message was fetched but the drawback here is that old commit messages (up to 30) from a new repo will all be marked with same (current) time.