Opened 11 years ago
Closed 7 years ago
#3611 closed defect (worksforme)
Ticket timestamps on https://trac.ffmpeg.org are in the future
Reported by: | grepfor | Owned by: | |
---|---|---|---|
Priority: | minor | Component: | trac |
Version: | unspecified | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
The ticket timestamps on https://trac.ffmpeg.org appear to be about 3 minutes in the future.
Example: I just modified ticket #3610 and pressed the submit button a few seconds after 15:58 UTC, but it then immediately appeared in the ticket list with a modification time of 16:01.
(Reference time on submission was verified on two machines both running NTP and synched, as well as a radio clock synched to WWV.)
Change History (5)
comment:1 by , 11 years ago
Summary: | Ticket timestamps on https://trac.ffmpeg.org timestamps are in the future → Ticket timestamps on https://trac.ffmpeg.org are in the future |
---|
comment:2 by , 11 years ago
Keywords: | timestamp removed |
---|---|
Priority: | normal → minor |
comment:3 by , 9 years ago
comment:4 by , 9 years ago
I don't know, I've not attempted to reproduce it since the original report. If you can suggest a way that I can try to reproduce it by filing some sort of "test" tickets that don't wind up annoying people, I'll be glad to do so and report what I find.
As for the snarky phrase "very important": Time skews between servers and underlying databases are not necessarily without consequences: Makefiles, database consistency checks, date/time related queries can all be affected in subtle ways by time skews. I reported the issue because it is something that I would have wanted to know about if I were an administrator of such a system.
The ticket was filed with priority "normal", then reverted to "minor". Per the definitions of ticker priority defined here
http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/issue_tracker.txt;hb=HEAD
"normal" has no definition at all, and "minor" is defined as:
"Bugs about things like spelling errors, "mp2" instead of "mp3" being shown and such. Feature requests about things few people want or which do not make a big difference."
In view of the above, I see no grounds for implying in a seemingly sarcastic way that the issue was considered to be "very important". Can you suggest a more constructive course of action upon noticing a problem, however minor, than filing a ticket on it?
If you can't make any such constructive suggestion, then let me suggest to you to avoid snarky comments to bug reporters who are trying, in whatever tiny way such as this, to contribute something of value or point out a potential problem.
comment:5 by , 7 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I couldn't duplicate this old issue. Time seems accurate to me.
Is this very important issue still reproducible?