Minecraft Tick Calculator

In Minecraft, you may sometimes think of time in seconds, while the game counts ticks in the background. A redstone door closes two steps too early, a hopper line empties more slowly than expected, or you enter a number into the /time set command but the sun does not stop where you want it to. Most of the time, the problem is not that the game is broken; it is that you are treating real time, game tick, and redstone tick as the same thing. This confusion happens often, especially for players who are new to redstone.

Game time does not flow like seconds

Minecraft’s basic rhythm runs on game ticks. In vanilla gameplay, the target speed is 20 game ticks per second. That means:

$$
1 \text{ second} = 20 \text{ game tick}
$$

One game tick is also equal to 0.05 seconds.

$$
1 \text{ game tick} = 0{,}05 \text{ second}
$$

On paper, it is very straightforward.

If you enter 60 seconds, that equals 1200 game ticks. 1 minute is likewise 1200 game ticks. 10 minutes is 12000 game ticks. The fact that a full Minecraft day cycle is 24000 ticks also becomes familiar from here; in a world running at 20 TPS, 24000 ticks is 20 minutes in real life.

When TPS drops, things change. 1200 game ticks take 60 seconds at 20 TPS. If the server drops to 10 TPS, the same 1200 ticks now stretch to 120 seconds in real life. What you look at in-game and ask “why was this delayed?” sometimes comes not from the circuit, but from the server being under load.

The main formula for time calculation is:

$$
\text{Game Tick} = \text{Saniye} \times \text{TPS}
$$

The reverse is written like this:

$$
\text{second} = \frac{\text{Game Tick}}{\text{TPS}}
$$

For vanilla, TPS is usually taken as 20. If the server is laggy and you are trying to understand the real waiting time, you need to enter the TPS as it is; otherwise the calculation remains theoretical.

This distinction is especially annoying in automatic farms and redstone circuits. A setup that works properly in singleplayer may behave more slowly on a crowded server. That is because the game still wants the same number of ticks; it just processes those ticks more slowly.

Redstone tick speaks a different language

In Minecraft, the word “tick” by itself is a bit tricky. When someone says “add a 10 tick delay,” you first need to understand whether they mean game tick or redstone tick. On the redstone side, 1 redstone tick is treated as 2 game ticks. At vanilla speed, this is 0.1 seconds.

$$
1 \text{ redstone tick} = 2 \text{ game tick}
$$

$$
1 \text{ redstone tick} = 0{,}1 \text{ saniye}
$$

10 redstone ticks equal 20 game ticks. But 10 game ticks are only 5 redstone ticks.

$$
\text{Game Tick} = \text{Redstone Tick} \times 2
$$

$$
\text{Redstone Tick} = \frac{\text{Game Tick}}{2}
$$

If you mix the two up, the circuit timing is off by a factor of two. In piston doors, item sorter locks, and observer chains, this difference shows up immediately. The door gets stuck where it should close, the piston cannot catch a block, or the sorter lets extra items through. Then people blame the wiring. Sometimes the wiring is innocent.

Repeater delay is therefore considered separately. A repeater can provide 1, 2, 3, or 4 redstone ticks of delay. If you want a longer delay, you place repeaters one after another.

Suppose a delay of 46 game ticks is required. First, we convert it to redstone ticks:

$$
46 \text{ game tick} \div 2 = 23 \text{ redstone tick}
$$

To build 23 redstone ticks with repeaters, you need 5 full 4-tick repeaters, with 3 redstone ticks left over.

$$
23 = 5 \times 4 + 3
$$

So the setup is read as:

5 x 4-tick + 1 x 3-tick.

This is also where rounding up comes into play. If the calculation does not land exactly on a redstone tick, it is safer to complete it to the next value instead of giving too little delay. After all, there is no half repeater setting. It is either 2 ticks or 3 ticks. Nothing in between.

The practical expression used on the repeater side is:

$$
\text{Repeater Redstone Tick} = \left\lceil \frac{\text{Game Tick}}{2} \right\rceil
$$

Then the number of 4-tick repeaters is found:

$$
\text{4-Tick Repeater Count} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

The remaining delay is obtained with a modulo calculation:

$$
\text{Remaining} = \text{Redstone Tick} \bmod 4
$$

In redstone, these small differences can sometimes become very large. Especially in fast piston setups, a signal arriving “one tick later” can determine whether the whole build works correctly or not. That is one of the unforgiving sides of the game.

Why do /time set values look strange?

A Minecraft day lasts 24000 game ticks. The sun’s movement, the day-night cycle, and the /time set command all work on this line. When you enter 6000 into the command, it becomes noon. Around 12000 is sunset. 18000 can be thought of as midnight.

But the clock logic does not start like the real world at first glance. Tick 0 is read in-game as roughly 06:00. That is why 6000 ticks corresponds to about 12:00. 18000 ticks falls around 00:00.

The in-day tick calculation checks the remainder of the entered tick value divided by 24000:

$$
\text{Day Tick} = \text{Game Tick} \bmod 24000
$$

So even if you enter 25000 ticks, the game reads it as the 1000th tick of the new day. Because after 24000, the cycle starts again.

The approximate calculation used for the clock equivalent is:

$$
\text{Hour} = \left\lfloor \left(\frac{\text{Day Tick}}{1000} + 6\right) \bmod 24 \right\rfloor
$$

For minutes, the remaining tick value is multiplied by 0.06:

$$
\text{Minute} = \text{round}((\text{Day Tick} \bmod 1000) \times 0{,}06)
$$

For 6000 ticks, the calculation gives approximately 12:00.

$$
\left(\frac{6000}{1000} + 6\right) \bmod 24 = 12
$$

Map makers use this a lot. It is also useful when taking screenshots. Sometimes even the direction of the shadow changes the scene; players who take in-game photos know that morning light and noon light do not feel the same.

This short list is easy to remember:

Writing 24000 and writing 0 lead to the same place in most cases. The game loops the cycle back to the start.

Waiting at hopper speed is a different problem

The hopper is one of Minecraft’s quietest parts, but also one of the parts that most often creates bottlenecks. It takes 8 game ticks to transfer one item to another inventory. At 20 TPS, this is 0.4 seconds.

$$
1 \text{ hopper transferi} = 8 \text{ game tick}
$$

$$
1 \text{ hopper transfer} = 0{,}4 \text{ second}
$$

The transfer rate of a single hopper per minute is calculated like this:

$$
\text{Item / Minute} = \frac{\text{TPS} \times 60}{8}
$$

If TPS is 20:

$$
\frac{20 \times 60}{8} = 150
$$

So a single hopper moves about 150 items per minute.

Consider a stack of 400 items. First, we find its tick equivalent:

$$
400 \times 8 = 3200 \text{ game tick}
$$

Then we convert it to seconds:

$$
\frac{3200}{20} = 160 \text{ second}
$$

160 seconds is 2 minutes and 40 seconds.

This number may look small, but it does not feel so small when you are standing by the chest while the farm is running. Especially if the system produces 300 items per minute and you are trying to collect them with a single hopper, clogging is inevitable. Items pile up, then a hopper queue forms, and then you start seeing items on the ground.

Seeing items on the ground is the storage system’s way of saying “I cannot keep up.”

There is one mistake to avoid in hopper calculations: this speed is for a single hopper. If multiple lines work in parallel, the flow increases. If the hopper chain is very long, each transfer brings its own delay. If there is a water channel, dropper line, chest minecart, or modded transport system, the situation changes. This calculation is mainly for quickly reading vanilla hopper behavior.

TPS affects real time here as well. While 400 items transfer in 160 seconds at 20 TPS, at 10 TPS this extends to 320 seconds.

$$
\frac{3200}{10} = 320 \text{ second}
$$

The in-game tick count is the same, but the real waiting time is doubled. This is sometimes why people ask on servers, “did the hopper break?” It does not break; the world has simply become heavier.

Which mode should be used when?

If your question is “how many seconds?”, a direct conversion is enough. For example, if you say “the door should close after 5 seconds,” 5 seconds equals 100 game ticks.

$$
5 \times 20 = 100 \text{ game tick}
$$

Knowing this much is enough for command blocks or simple delay tasks.

If you are building a redstone circuit, look at repeater delay. Because what you place in the game is not seconds, but a repeater setting. A 2-second delay is 40 game ticks, meaning 20 redstone ticks.

$$
2 \times 20 = 40 \text{ game tick}
$$

$$
40 \div 2 = 20 \text{ redstone tick}
$$

20 redstone ticks can be built with 5 4-tick repeaters.

For Minecraft time, you need a /time set value. If you want “make it noon,” use 6000; if you want “make it midnight,” use around 18000. Here, you are not talking about seconds, but the tick position within the day.

On the hopper side, the question is completely different: “How long will this many items take to flow?” It makes more sense to enter the item count and see the time. This is especially useful for understanding whether a single hopper is enough at the output of automatic farms.

Unit selection matters. Game tick, redstone tick, seconds, minutes, hopper transfer, and Minecraft day may look like different faces of the same thing, but they are used for different decisions in the game. You can think of seconds as human time, game ticks as game time, and redstone ticks as circuit time.

A bit rough, but it works.

If the calculation is correct, why does the game behave differently?

Even when the tick calculation is correct, the in-game result may not match exactly. There are a few reasons for this.

The first is TPS. If the server is not running at 20 TPS, real time extends. By the time the game says “1200 ticks have passed,” you may have waited more than 60 seconds in the real world. The command, redstone, or hopper calculation is not broken; it simply completes later.

The second is chunk loading. If a chunk is not loaded, some systems there do not work as expected. Hopper lines, farms, redstone clocks; all of them depend on the world remaining active. A setup you leave far away may not always continue operating the way you imagine.

The third is redstone update order. Redstone is not only a time calculation. Where the signal comes from, which block updates first, repeater direction, comparator behavior, and what the piston detects and when all come into play. Sometimes 4 ticks is the correct value, but the circuit layout is wrong.

There are also Java and Bedrock differences. Even though most basic timing ratios look the same, version differences in redstone behavior can be a headache. It is not surprising when you watch a Java circuit on YouTube and build it exactly in Bedrock, only to find that it does not work.

The calculator does not perform magic at this point. It gives you the timing side cleanly. The rest is determined by the physical layout of the game.

A few small but useful habits

First, clarify which tick the word “tick” refers to. Is it game tick or redstone tick? Starting a circuit calculation without asking this is a bit like placing blocks without measuring.

Do not rely on single-hopper speed in long hopper lines. If a farm produces more than 150 items per minute, a single line will eventually clog. Whether you need two lines, a water stream, or a dropper clock depends on the design.

For /time set commands, instead of memorizing every number, know a few main points: 0 morning, 6000 noon, 12000 evening, 18000 midnight. The rest can be adjusted by eye. Minecraft is partly a game of eyeballing things anyway.

For repeater delay, thinking in 4-tick blocks makes things easier. First convert the delay to redstone ticks, then divide it into groups of 4. If the remainder is 1, 2, or 3, add one more repeater at the end.

Do not completely forget TPS either. In a singleplayer world, assuming 20 TPS is usually enough. If things start acting strangely on a server, checking TPS first is smarter. Before tearing apart the redstone line, that is.