clocks during analysis.

I checked and apparently FICS does store the move times so... ignore my first paragraph.

Most recent Fics games are stored, with move time :

http://ficsgames.org/

213,524,471 games stored

For example :
http://ficsgames.org/cgi-bin/show.cgi?ID=378247896

click "toggle movetimes".

Maintainer of ficsgames database is : Ludens.
http://ficsgames.org/cgi-bin/search.cgi?player=ludens&action=Finger

"It's more that with 100 million games in the database and growing fast it's a gray area in terms of cost vs. benefit."

^

i like the idea aswell, its featured on other chess websites too

Considering the amount of space it takes to store all played games on this server I would be surprised if also adding time information would be very critical. If time information already is stored, like achja says, it wouldn't requre much extra computer power to show it.

Sometimes when I examine games it is interesting to see the time to get an idea if time trouble can be a reason for someone playing like they do for examole.

Uniheidron: "It's more that with 100 million games in the database and growing fast it's a gray area in terms of cost vs. benefit."

You don't need to store clock time, like (5:32) for every move. You can store the time control and then only the thinking time for every move , which in blitz often is a one digit number. I'm not a programmer but maybe that can save some space.

Another possibility is to limit the database in time backwards and delete games after a certain time. If you play an interesting game it's possible to save it.

#17 One digit move times is basically what Lichess does now and it's just too much rounding to keep the clock accurate over a short time control.

I'm not sure this works or will ever be worth it, but I had one idea for solving the rounding problem without using much space. I apologize in advance since this idea is probably very flawed; but it was fun to think about!

-------------------

Divide the game into N dividers and record the number of dividers you pass on the move when you pass them. If you decide to save 256 dividers, then in a 1 minute game you would get pretty good accuracy to ~0.25 seconds (60/256 sec), and for a 5 minute game ~1 second (300/256 sec). In the PGN, you record how many dividers were passed alongside each move. Most moves will only pass a small number of dividers, because if a player passes a large number of them it means they used up a significant portion of their time. They can't do that very often in a game or they lose on time.

You could record something like this:
1. e4 {0} e5 {0} 2. d4 {1} exd4 {3} 3. c3 {5} dxc3 {2}

Which would translate to clock times that are like this:
1. e4 {1 min} e5 {1 min} 2. d4 {255/256 min} exd4 {253/256 min} 3. c3 {250/256 min} dxc3 {251/256 min}

With increment, you'd just need to be able to use a few negative numbers. In a 3min+2sec game, the largest fraction you could add to the clock is 2/180 so for 256 dividers you'd only need to be able to go down to -3, since even with a premove a player can never go back more than 3 dividers in one move.

In a bullet time scramble with lots of premoves the clock might look frozen since players are only passing a divider every handful of moves, but you'd still understand what was going on.

You don't even have to uniformly distribute the dividers. If you use some sort of logarithmic formula to set them then you can get increased accuracy at the end of the game at the cost of slightly less accuracy earlier on.