HUD time display ({time} / server time) uses gameTime (world age) instead of World Clock on 26.1+ #6665

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/meteor-client@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

• Meteor Client 26.2 Move to brigadier for commands #23
• Minecraft 26.2, Fabric
• PaperMC 26.2 build Added Skylight Updates to NoRender #123