fix: more recent vallis anchor

[TobiTenno]

What did you fix?

Contributed by mettwasser in discord

corrects the occasional drift

---

Reproduction steps

---

Evidence/screenshot/link to line

Considerations

• Does this contain a new dependency? [No]
• Does this introduce opinionated data formatting or manual data entry? [No]
• Does this pr include updated data files in a separate commit that can be reverted for a clean code-only pr? [No]
• Have I run the linter? [No]
• Is is a bug fix, feature request, or enhancement? [Maintenance]

Summary by CodeRabbit

• Bug Fixes

  • Fixed time calculation used for cycle timing, ensuring next/remaining cycle times are computed correctly.

• Chores

  • Updated a fixed reference timestamp used by the cycle scheduler.

Impact: Cycle start/end and time-until updates may now display corrected values.

[coderabbitai]

📝 Walkthrough

Walkthrough

Updated the VallisCycle model: the fixed start timestamp (lStart) was changed to February 4, 2026 19:46:48 UTC and the time-difference computation in getCurrentCycle was corrected to use lStart.getTime() instead of lStart.getMilliseconds(). No other control flow changes.

Changes

Cohort / File(s)	Summary
Vallis cycle model lib/models/VallisCycle.ts	Replaced the fixed start timestamp (lStart) with a new date (2026-02-04T19:46:48Z) and fixed time-difference calculation by using lStart.getTime() instead of lStart.getMilliseconds(). No other logic or exports altered.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Suggested reviewers

• AyAyEm

Poem

🐰 I hopped the clock from old to new,
A tiny fix, a timely view,
Milliseconds swapped for epoch's chime,
The Vallis cycle keeps its time,
One rabbit cheers — synchronous and true 🥕✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'fix: more recent vallis anchor' is specific and directly related to the main change—updating the Vallis cycle anchor timestamp to a more recent value and fixing the time calculation method.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch TobiTenno-patch-1

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

lib/models/VallisCycle.ts (1)

38-38: ⚠️ Potential issue | 🔴 Critical

Critical bug: getMilliseconds() should be getTime().

Date.prototype.getMilliseconds() returns only the millisecond component of the date (0–999), not the epoch timestamp. Since lStart has no fractional seconds, .getMilliseconds() returns 0 for both the old and new anchor dates, making the entire anchor constant irrelevant. The calculation effectively becomes Date.now() % loopTime.

This is the actual root cause of the drift the PR intends to fix. Without correcting this line, the anchor update on Line 5 has no effect.

🐛 Proposed fix

-  const sinceLast = (Date.now() - lStart.getMilliseconds()) % loopTime;
+  const sinceLast = (Date.now() - lStart.getTime()) % loopTime;

🤖 Fix all issues with AI agents

In `@lib/models/VallisCycle.ts`:
- Line 5: The anchor constant lStart is fine but the code that reads its numeric
epoch uses lStart.getMilliseconds() (see usage of lStart) which returns only the
milliseconds part (0) instead of the full epoch; change that call to
lStart.getTime() so all cycle math uses the full timestamp, then verify the
provided timestamp '2026-02-04T19:46:48Z' truly aligns to an in-game warm↔cold
boundary so reported cycle times won't be shifted.

🧹 Nitpick comments (1)

lib/models/VallisCycle.ts (1)

10-10: Nit: Typo in interface name — CurrnetCycle → CurrentCycle.

Pre-existing, but since you're touching this file: the interface is misspelled. Also, the JSDoc on Line 66 says "Earth Day/Night Cycle" and Line 82 says "cetus cycle" — both should reference Orb Vallis.

[github-actions]

🎉 This PR is included in version 5.2.16 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀