Summary
On Minecraft 26.1 and later, the time displayed by Meteor's HUD (the Starscript {time} variable, used e.g. by the Info HUD's "Server time" line) no longer matches the actual day/night cycle.
Observed behavior
Tested on Meteor 26.2 (#23) against Paper 26.2:
- The displayed time keeps ticking on its own schedule, even as the world visibly changes.
/time set day, /time set night, /time add etc. have no effect on the displayed value, while the sky, clock items in item frames, and daylight detectors all react correctly.- Every Meteor user on the server sees the same, wrong value — it behaves like a second, independent clock.
Root cause
Minecraft 26.1 reworked time into data-driven World Clocks: /time and the day/night cycle now operate on World Clocks, while Level#getGameTime() is the world/simulation age and is explicitly unaffected by /time changes (as documented in the 26.1 release notes: time query gametime is independent of World Clock changes).
Utils#getWorldTime() in src/main/java/meteordevelopment/meteorclient/utils/Utils.java still formats the world-age counter as if it were time of day:
int ticks = (int) (mc.level.getGameTime() % 24000);
ticks += 6000;
if (ticks > 24000) ticks -= 24000;
The result looks like a clock but is actually world age mod 24000, which only ever matches the real time of day by coincidence.
Suggested fix
Read the dimension's default World Clock — the same clock /time targets when no explicit clock is given — instead of getGameTime():
long ticks = Math.floorMod(mc.level.getDefaultClockTime(), 24000L);
ticks = (ticks + 6000L) % 24000L;
Math.floorMod + modulo wrap also fixes the if (ticks > 24000) hand-rolled wrap's edge case at exactly 24000 ticks and is safe for negative clock values.
I've implemented and tested this in a fork: Promptt001@45740ad (release with a build for 26.2: https://github.com/Promptt001/meteor-client/releases/tag/v26.2-worldclock-hud). With the patch, the HUD immediately follows /time set day|noon|night|midnight and matches clock items / daylight detectors, as expected.
One open design question: Level#getDefaultClockTime() is dimension-aware, so a dimension whose default clock is not a standard 24,000-tick day (custom datapack clocks) may not render meaningfully as HH:MM. If the intended semantics are "Overworld time everywhere", Level#getOverworldClockTime() would be the alternative.
Environment
Summary
On Minecraft 26.1 and later, the time displayed by Meteor's HUD (the Starscript
{time}variable, used e.g. by the Info HUD's "Server time" line) no longer matches the actual day/night cycle.Observed behavior
Tested on Meteor 26.2 (#23) against Paper 26.2:
/time set day,/time set night,/time addetc. have no effect on the displayed value, while the sky, clock items in item frames, and daylight detectors all react correctly.Root cause
Minecraft 26.1 reworked time into data-driven World Clocks:
/timeand the day/night cycle now operate on World Clocks, whileLevel#getGameTime()is the world/simulation age and is explicitly unaffected by/timechanges (as documented in the 26.1 release notes:time query gametimeis independent of World Clock changes).Utils#getWorldTime()insrc/main/java/meteordevelopment/meteorclient/utils/Utils.javastill formats the world-age counter as if it were time of day:The result looks like a clock but is actually
world age mod 24000, which only ever matches the real time of day by coincidence.Suggested fix
Read the dimension's default World Clock — the same clock
/timetargets when no explicit clock is given — instead ofgetGameTime():Math.floorMod+ modulo wrap also fixes theif (ticks > 24000)hand-rolled wrap's edge case at exactly 24000 ticks and is safe for negative clock values.I've implemented and tested this in a fork: Promptt001@45740ad (release with a build for 26.2: https://github.com/Promptt001/meteor-client/releases/tag/v26.2-worldclock-hud). With the patch, the HUD immediately follows
/time set day|noon|night|midnightand matches clock items / daylight detectors, as expected.One open design question:
Level#getDefaultClockTime()is dimension-aware, so a dimension whose default clock is not a standard 24,000-tick day (custom datapack clocks) may not render meaningfully as HH:MM. If the intended semantics are "Overworld time everywhere",Level#getOverworldClockTime()would be the alternative.Environment