I am using Moltbot v2026.1.27-beta.1 on an Aliyun ECS instance (CentOS/Linux). My system time is correctly synchronized with NTP, but I am encountering a critical bug where the bot generates "expired" or "historically incorrect" timestamps when creating scheduled tasks (Cron jobs).
Environment:
System Date:
Fri Jan 30 10:04:25 CST 2026(Verified viadatecommand)Moltbot Version:
2026.1.27-beta.1Location: Overseas Server (configured with Asia/Shanghai timezone)
The Issue: When I ask the bot to "remind me in 1 minute", it successfully creates a task object, but the calculated atMs is completely wrong.
{
"name": "60秒后测试消息",
"createdAtMs": 1769738829379, // Corresponds to Jan 30, 2026 (Correct)
"schedule": {
"kind": "at",
"atMs": 1748329500000 // Corresponds to May 27, 2025 (WRONG!)
}
}
Observation:
The
createdAtMsis correct (2026).The
atMs(scheduled execution time) is pushed back to 2025, making the task instantly expired.Even after explicitly instructing the bot to "save to memory: do not use incorrect timestamps" or providing the exact current epoch, the bot's internal logic seems to apply an incorrect timezone offset or an overflow during the relative time calculation.
Since
atMs<createdAtMs, thenext-heartbeatnever triggers the notification.
Question: Is this a known bug in the beta.1 scheduler's timezone handling? How can I force the Gateway to use the system's local time instead of its internal (incorrectly calculated) UTC offset?