Villagers stop working and sleeping in worlds a few years old

Does time naturally advance this way once it gets close to the Integer.MAX_VALUE limit?

Is your gamerule tick-rate set to the default?
Are you using a command block to speed up or slow down the passing of time?

I'm wondering that if you have the default tick speed, and no command blocks, just vanilla gameplay, if this would still even happen? perhaps it was forced into the negatives by skipping the value it checks for (checking for greater than max value and not for less than min value, negative numbers). I assume your proposed fix would fix this issue, I'm just curious if this would occur naturally, and after how long? 2,147,483,648/200 (bedrock tick speed) by my calculations, this would only naturally occur after one hundred and eighty hundred thousand (180,000) minutes, or 124 real life days. I've played on a worlds much older than this, yet have never once ran into this issue, is why I ask. My question is, does this have to do with speeding up time? Or maybe do you have your time day cycle in game set to match real life days? (I have a friend who did this with his world).

@johnathoni: Random tick speed is unrelated to how game time progresses. The game time is just a count of ticks. Random tick speed is just how many blocks are randomly updated in each chunk section on each tick.

There are 20 ticks per second, so 2^31 ticks is reached after about 30,000 hours or 1,250 real-life days.

@Matt Smith are you using any add-ons or command blocks on the realm that might be advancing the time count? Perhaps a one-player sleep system?

Or do you see any other evidence that the time count is advancing unexpectedly?

Possibly the same issue as MCPE-86843.

Reopening b/c this issue should be looked at regardless of whether OP answers my question about the 1-player sleep system. I suspect those are a contributing factor to the world age getting so high, but I don’t see anything wrong with using them. They are just command block systems and not an exploit as far as I know. EDIT: silly me, the 1-player sleep system is clearly laid out in the test world. I should have looked at that first.

The fact that worlds can only handle an age of 3 and 1/2 years before running into this issue, with or without a command block sleep system, is a problem. It’s especially a problem for Realms that might be active around the clock with players from different places in the real world.

I just helped another user who had this issue on a realm.

This does appear to be the cause of linked "MCPE-86843 Villagers either don't sleep or don't wake up".  

Coming in from MCPE-86843 here.  

This bug affects local worlds as well as realms.   Although we started keeping a persistent world in preparation for the better together update, I've owned MCPE on android since 2011 and could potentially have nearly 9 year old maps.   As I reported in the other bug, we ran the world as a server with a 24/7 dummy account for over a year and even without single player sleep command blocks we'd be hitting 3.5 years already.  

Does this affect BDS as well?  or does time stop progressing on BDS when no one is connected? 

That's a really good question. My guess would be that since BDS has to be started up and shut down manually, it probably runs the world continuously, but I don't know that for a fact. If it does, it certainly would be possible to keep a world running for 3.5 years solid, so all the better reason this bug needs a fix.

I do have a question though. The report is that villagers either will not sleep or will not stop sleeping, will not reset their trades, and will not spawn iron golems. Not counting nitwits, all villagers sleep during the period from tick 12000 within the day to tick 24000 (actually tick 0 of the next day). They reset their trades when they arrive at their workstations, which they do twice a day, once in the morning and once following the gathering. So these behaviors are dependent on the clock incrementing at a steady pace. Spawning an iron golem doesn't occur on a schedule, but it's conditioned on 75% of the employed villagers having worked in the last day, so it's at least somewhat dependent on time incrementing normally. But is it possible that a one-player sleep system is in a loop, constantly trying and failing to change the time, so the clock incrementing is continually getting reset and time is not progressing? That could explain the symptoms and also why the high water mark of the clock is 12 hours before it wraps around.

I'm not saying it wouldn't need to be fixed if that's the case. It would mean that the problem isn't actually a bug (or at least, that the game might work as intended in the absence of a sleep system). But these sleep systems are popular and common and not exploitive, and Mojang always tries to support creative ways the community comes up with to solve problems, so I would expect they would look for a way to solve this even if it isn't a bug. It's just that if we know whether it's bug versus a design problem, this report can be directed to the right people sooner.

I've done some digging and discovered that the Time variable in level.dat actually skips ahead by up to 12000 even during normal player sleep, so the issue here is less related to one-player sleep systems than we thought. Time is used to keep track of the daylight cycle. The difference between the present value of Time and the nearest multiples of 24000 determines which part of the day the world is at. Time increments with each tick if dodaylightcycle is on, and it advances to the next multiple of 24000 when players sleep. According to MCPE-43394, the /time set command always increases Time, either by advancing to a later part of the present day, or by advancing to the next day when setting an earlier time-of-day than present. Howerver, /time set never adds more than 24000 to Time.

There is no special coding to handle Time naturally incrementing beyond 2^31. It simply rolls over to -2^31 and continues to increment. When it does so, it triggers the problems described in this report. Here is my test:

1. Create a world with dodaylightcycle on.

2. Spawn a villager and place a bed and workstation so that it links.

3. Using an NBT editor, edit Time to be close to 2^31.

4. Open the world and wait.

5. After observing that the villager either doesn't go to bed at night or doesn't work in the daytime, close the world and check Time with the NBT editor. It will be negative.

There is another variable in level.dat that keeps track of the world's total running time: currentTick. This variable actually increments beyond 2^31 and even 2^32 without issue. It stays positive. In my 2 local survival worlds that have never had cheats enabled, Time is 20-25% higher than currentTick. In Francois Gurin's level.dat (from MCPE-86843) currentTick is at 546,663,823. That corresponds to about 316 real-world days of running time. It doesn't seem to fit his year of 24/7 running but it is a big number nonetheless.

Auldrick asked

But is it possible that a one-player sleep system is in a loop, constantly trying and failing to change the time, so the clock incrementing is continually getting reset and time is not progressing?

Based on my test above it's Time being a negative number, and not command systems per se, that causes the villager issues. I think there are two possible reasons why:

1. Once time rolls over to the negatives, the villager schedules, sky cycle, and /time command results no longer synchronize. Along these lines the negative time might cause the sort of failure loop you describe.

2. Villager AI cannot process negative Time values. For example, villager schedules may depend on detecting when the remainder of ( Time / 24000 ) is greater than certain certain amounts, but it never comes out greater if time is negative.

For what it's worth, I suspect #2 because the sky seems fine and one-player sleep systems seem to work fine with negative Time.