Opened 3 years ago

Closed 7 days 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 Changed 3 years ago by grepfor

  • Summary changed from Ticket timestamps on https://trac.ffmpeg.org timestamps are in the future to Ticket timestamps on https://trac.ffmpeg.org are in the future

comment:2 Changed 3 years ago by cehoyos

  • Keywords timestamp removed
  • Priority changed from normal to minor

comment:3 Changed 2 years ago by richardpl

Is this very important issue still reproducible?

comment:4 Changed 2 years ago by grepfor

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 Changed 7 days ago by llogan

  • Resolution set to worksforme
  • Status changed from new to closed

I couldn't duplicate this old issue. Time seems accurate to me.

Note: See TracTickets for help on using tickets.