/time set does not set the time to the value provided

Confirmed in 1.11.0.8 Beta on Windows 10, but with corrections.

In 1.10, /time set would set the current daytime (time of day) without changing the day. It was therefore possible to set the clock backward within the current day.
In 1.11, this is no longer possible. If the value specified in /time set value is less than the current daytime, the clock will be rolled forward to the specified time the next day.

Presumably, this has to do with the implementation of villager schedules, perhaps because rolling the clock back would cause villager events to fire out of order in a way that would break the game. However, there has been no mention of this in the changelogs.

Also of note is that whereas 1.10 used to display (in chat) "Set the time to" the new daytime, 1.11 displays this value + 24000 * the /time query day value. For example, my "/time set 1000" command was answered with "Set the time to 49000". It's hard to see how this could be intentional, since after just a few Minecraft days of playing it makes it hard to figure out what the time of day is.

Yeah, it definitely changed in 1.11. Now just typing /time set 0 keeps adding days instead of, well, setting the time to zero

True, but only if the daylight cycle is enabled. If it's disabled, the time isn't changed because it doesn't need roll the clock backwards.

Feel free to change the report for the new things you've noticed in 1.11. Otherwise I might just change it to "time set doesn't do what it says" 😛

I've done a more thorough study of the command and learned the following:

There are two independent time counters in the game, which I'll call Gametime and DayClock.

• Gametime is the number of ticks elapsed since the world was created. It increments continuously, including when the daylight cycle is disabled, and can be displayed but not changed or stopped. It's mainly used for scheduling future events such as weather changes, spawning patrols, and the like. In my mind, it's not very useful to a player.

• DayClock is the current day and time within the daylight cycle. Basically, it's a date/time value that only increments while the daylight cycle is enabled. It controls the sky contents, skylight levels, scheduled villager behaviors, and anything else that's linked to the apparent time of day. This clock can be set, incremented, and decremented using commands.

The /time query command displays the current values of these time counters as follows:

• /time query gametime displays the value of Gametime. It's the only command that uses Gametime.

• /time query daytime displays the value of DayClock mod 24000. In effect, daytime is the Minecraft current time of day as reflected by the sky contents.

• /time query day displays the value of int(DayClock / 24000). In effect, day is the Minecraft current relative day number, except that it can be changed by commands.

The /time set command sets the value of the DayClock counter. The argument represents what time of day you want it to be in the range 0 to 23999. The argument value is forced into this range using the modulo operation. In effect, this command rolls the time of day forward only to the specified time of day, incrementing the day number if it passes 24000 (the start of the next day). The argument can also be a TimeSpec keyword, which is converted to an integer as follows:

After setting the new DayClock value, the command displays its value.

The /time add command adds the argument value to the DayClock counter. The argument is the number of ticks to add, and may be negative. This command can change both the relative day number and the time of day. A negative argument value will effectively roll the clock backward.

So the question now is, what has changed, and is it a bug?

I think the only thing that's changed is that /time set used to display the daytime value, but now it displays the full DayClock value, which implicitly includes the relative day number. The value it displays is opaque and much harder to use, so it should be reverted to the earlier behavior.

It's possible that forcing the /time set argument range to 0 to 23999 is also a change. The wiki says this command sets the "world game time", but it never really defines what that term means. In Bedrock, at least, it means the time of day based on how the command now acts. I don't know and am unable to test how it used to act or how it acts in Java Edition.

In java, /time set and /time add modify what you called game time directly.

I...don't think so. Gametime isn't tied to the daylight cycle. Changing it wouldn't have a visible effect, and it could mess up the scheduling of future tasks that remain scheduled across save and reload.

You probably meant it updates what I called DayClock, but how? Does set force its argument into the daytime range like Bedrock does? And does it display the DayClock value as opposed to the calculated time of day in ticks?

Well in java edition, the daylight cycle is directly calculated from the game time. There is only one ticking timer

It's probably true that there is only one ticking timer, but it doesn't imply your conclusion. The ticking timer no doubt increments both Gametime and DayClock, but only DayClock can be changed by commands.

My rationale for saying this is that at least some scheduled events have to be based on a continuous, stable epoch, because if you allow discontinuities in your time scale, the expiration time of a timer based on that scale might never occur at all. So Gametime has to steadily increment forever. But using /time set introduces a discontinuity, so you can't calculate the daylight cycle time from Gametime alone, you'd have to track and remember the sum of the offsets introduced by /time set commands and apply that to know where the sun is in the sky. DayClock is nothing more than Gametime plus the sum of the offsets, plus a constant that's needed to convert one epoch to the other.

(Full disclosure: I don't know that DayClock exists in the form I described it—it could alternatively be stored as two separate values, relative day number and tick within the day, for example. But the equivalent information has to exist in the world in some form because of the argument above, and all the possible alternative stored forms are linear functions of each other. I didn't have information about the precise storage format, so I chose one that seemed relatively easy to describe.)

Okay, I stopped being silly and looked further.
You're right, java does have an onward-marching clock that cannot be changed. It is the result of /time query gametime.
However, I can use /time to switch to any day, not just move forward.
/time set 50000 results in the following:
/time query day --> 2 (third day)
/time query daytime --> 2000 (2000 ticks into current day)

Ok then, assuming Bedrock originally did the same thing, 1.9 must have changed it, and given that /time add can be used to set it to any day you like (though calculating the argument value is a bit tricky), it seems likely that the bug is that /time set is interpreting its argument differently from Java. I guess that could have been intentional, but I can't guess the reason.

I left a request for Mega_Spud to look at this again for possible forwarding to ADO.

FYI this report no longer accurately describes the state of the game. The new behavior is as follows:

• create a new world

• /time set 500000
  → ❌ Set the time to 20000 (expected: "set the time to 500000")

• /time query day
  → ❌ Day is 0 (expected: "day is 20")

• /time set 0
  → ❌ Set the time to 24000 (expected: "set the time to 0")

• /time query day
  → ❌ Day is 1 (expected: "day is 0")

In other words, /time set is basically transformed into a fake /time add, making it impossible to do anything except increase the current day.
See Auldrick's comment below

Actually, you can decrease the current day, by using /time add with a negative argument. You just can't do it with /time set.

I finally rewrote this report to actually make sense and describe the issue and limitations

Should not have been closed Fixed until the fix reaches the regular release.