Comment is shown with a date in the future
Summary
I posted a comment to an issue report on a project on Heptapod (namely mercurial/tortoisehg), and right after publishing my comment, it was displayed like this:
Note the date is "in 14 seconds", that is, in the future
Steps to reproduce
I don't know if you can reproduce, as my guess is it depends on the date on your computer, i.e. on the client side (that is my guess because I can't imagine in what other way you can get such an error).
Anyway what I did to reproduce the issue was:
- comment on an issue
- look at the comment you just posted
What is the current bug behavior?
The date of the comment is shown as being in the future
What is the expected correct behavior?
Right after posting the comment, the date should be displayed as "just now". After a while, it should be some date and time in the past (whether it's expressed as an absolute date and time, or in terms of "XXX ago"), NEVER under any circumstances can it be in the future. I don't expect it to be 100% accurate, but I do expect not to see an impossible value.
I can imagine a couple of ways this could happen, both if the time in my computer's clock (or your server's, or both) is slightly off:
A) When you receive and store the comment, you store the date as submitted by the client, so if the client's clock is off, the date of the comment is stored wrong
B) much more likely: when displaying the date, on the client side, you compare the date of the comment as it comes from the database (which was determined by the server) with the current date from the client's clock.
Either way it's wrong. You can't ever compare two dates that come from different clocks and assume they are correctly synchronized. If you have no other option than doing that (but that's not the case), then a small error is acceptable; but saying that something happened in the future is not.
You shouldn't assume that the time on the user's computer is even remotely correct. But if you do decide, for the sake of simplicity, to assume that the clock on the user's computer is reasonably correct, then you have to take into account the possibility of a reasonable error, say a few seconds or minutes. That basically boils down to clamping the "time ago" value to >= zero.
If it's none of those and you are only using server-side times, as you should, then I have no idea how you can be ending up with a negative time-ago value.