1.Suggestion for effects.json: Support for daycount-related parameters:
Currently, effects.json includes time-related parameters but does not utilize daycount-related ones. Would it be possible to add support for day-based effects as well?

2.Issue with day variable desync when using time skip functionality:
Currently, the day variable increments by 1 when in-game time reaches 24,000 ticks. However, this causes desynchronization between the day counter and the actual elapsed days when using time-skip features.
Suggested Fix:
Could the day value instead be calculated by dividing the world's total tick count by 24,000? This would ensure automatic synchronization with the true in-game day count, even after time jumps.

3.The "changenumber" is not functioning correctly. After the string is split by the = sign, the latter part of the string fails to correctly append an empty string "". The SET feature, which checks whether the operator is an empty string "", does not work as intended because it fails to properly identify the empty string "" and treats it as if the operator does not exist.

4.Issue with areas.json when using sphere:
The isInSphere method currently uses:
return (dx * dx + dy * dy + dz * dz <= this.dimx * this.dimx + this.dimy * this.dimy + this.dimz * this.dimz)
This incorrectly scales up the sphere's radius when multiple dim parameters are present.
Suggestion:
Use the largest value among the dim parameters, or
Introduce a new parameter specifically for the radius?

For issue 2. That's on purpose separate from Minecraft time. You can use the /incontrol days command to control time otherwise. I will not change that

I'll check the other features. BTW, what version?

MC1.20.1，Forge47.3.0，Issues 1, 2, and 4 were tested with mod version 9.2.11, while issue 3 was tested with version 9.2.6 and hasn't been verified on 9.2.11.

Additional Suggestions:
Currently in array-type [] Conditions, only scoreboardtags_any uses OR-gate logic for evaluation, while all others use AND-gate by default. Have you considered adding a parameter to control the evaluation logic for array Conditions? This would allow switching between OR-gate or even NOT-gate evaluation modes when needed.

Would it be possible to add a command for dynamically creating areas in areas.json? For example:

• Specify a new area name

• Set its location coordinates

• Reference an existing template area from areas.json

This would create a new area at the specified location with the same configuration as the template area.