Forums : Feedback Forum
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.blackduck.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
Bug in dates
I just found an interesting bug while looking at the commits in Cogito.
It says that the last commit was over 97 years ago, but that's not the most strange thing. The problem is that the last commit is actually dated as 97 years in the future!
I know Ohloh is getting better at keeping projects up to date, but I don't think it's yet capable of guessing future commits xD
Heh, you guys are killing me with your funny repos :-).
It looks like the commits in question do not have valid dates in the repository itself:
~/cogito$ git cat-file -p ee7bcf6d7aeb805bfdaf81b9d01ab744b36ed439
tree fc11af5002bf6eb8daa1fdd4ce50baf4b0c30aff
parent 4d15081c47b2d5c80929f209ed22bd639e152295
author Junio C Hamano 4294967295 -0700
committer Petr Baudis 1113549567 -0700
This timestamp is way out of range. If you view this commit with a regular git log, it's displayed as the UNIX minimum date (Jan 1, 1970).
To work around this, I suppose we can check for dates that are out of bounds, and clip them somehow. In this particular case, we could probably use the committer date instead of the author date.
I'll add the workaround to the bug list on our SCM lib, but I admit to no wrongdoing :-).
Robin
