Intermittently corrupted JavaScript Date output in Node-RED Function node

未關閉
#67,145 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
45/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
javascript, node.js
領域
backend

研究方向

Start with the provided Function-node examples and verify the behavior in a minimal standalone Node.js script using the same Date values and methods. Compare the formatted strings with getTime() to determine whether the corruption reproduces outside Node-RED and on which environment. Done means the cause is isolated or the report is narrowed to a reproducible case; the issue names no relevant source files or tests.

由索引模型根據 Issue 內容生成。

描述

Version

24.22.1

Platform
Home Assistant OS
Node-RED add-on: 22.2.1
Node-RED: 5.0.9
Node.js: 24.22.1
Architecture: aarch64, Raspberry Pi 4
Mozilla FireFox
Subsystem

No response

What steps will reproduce the bug?

Description

In a Node-RED Function node, JavaScript Date objects intermittently produce corrupted string representations, even though their numeric timestamps remain correct.

For example, a timestamp is correct when retrieved using getTime(), and the object passes both instanceof Date and constructor.name === "Date". However, methods such as toISOString(), toString(), and toLocaleString() sometimes return malformed output.

Examples observed include:

Expected:
2026-10-29T12:39:10.726Z

Actual:
2026-10-29T12:3935.726Z

The problem is intermittent. The same code normally produces correct output, and the numeric timestamp remains correct when the malformed output occurs.

The issue also affects newly created Date objects, not only objects stored and retrieved through Node-RED context. This suggests that the issue may not be specific to flow.set() or flow.get().

A control test using new Date(0).toISOString() consistently produced the expected output:
1970-01-01T00:00:00.000Z
Expected behaviour

JavaScript Date methods should consistently return valid date strings corresponding to the object's numeric timestamp.
Actual behaviour

Date strings occasionally contain unexpected digits inserted into the time portion, while getTime() continues to return the correct timestamp.
Question

How often does it reproduce? Is there a required condition?

Maybe 1 out of 5 times

What is the expected behavior? Why is that the expected behavior?

Expected:
2026-10-29T12:12:18.249Z

What do you see instead?

Actual:
2026-10-29T1249208.249Z

Additional information

if you look at the HoldDateTime1 it should be written like :
2026-10-29 16:16:42 but it becomes 2026-10-29 1653:42

I log to database from a lot of nodes, and then by query the database I see the results.

This is how the sender sees it:
lastDiff:24798
timestamp:1793287002346
iso:2026-10-29T15:16:42.346Z
type:object
HoldDateTime1:2026-10-29 16:16:42
HoldDateTime2:2026-10-29 16:16:52

This is what it becomes:
holdDateTime1:2026-10-29 1653:42
holdDateTime1:Thu Oct 29 2026 1653:42 GMT+0100 (Central European Standard Time)
Timestamp1: 1793287002346
ISO2: 2026-10-29T1553:42.346Z
IsDate: true
Constructor: Date
Time: 1793287002346
ISO: 2026-10-29T1553:42.346Z
holdDateTime2:2026-10-29 1653:52
Timestamp2: 1793287012346
ISO2: 2026-10-29T1553:52.346Z
--- HoldDateTime2 ---
IsDate: true
Constructor: Date
Time: 1793287012346
ISO: 2026-10-29T1553:52.346Z

the code that creates the Flow.set()
let holdDt1 = new Date()
holdDt1.setTime(holdDt1.getTime() + lastDiff - 5000);
flow.set("HoldDateTime1",holdDt1)

msg.ReportStr += "\nlastDiff:"+ lastDiff
msg.ReportStr += "\ntimestamp:"+ holdDt1.getTime()
msg.ReportStr += "\niso:"+ holdDt1.toISOString()
msg.ReportStr += "\ntype:"+ typeof holdDt1

msg.ReportStr += "\nHoldDateTime1:" + holdDt1.toLocaleString("sv-SE")
let holdDt2 = new Date()
holdDt2.setTime(holdDt2.getTime() + lastDiff + 5000);
flow.set("HoldDateTime2", holdDt2)
msg.ReportStr += "\nHoldDateTime2:" + holdDt2.toLocaleString("sv-SE")

The code that receives via flow.get()
msg.ReportStr += "\nholdDateTime1:"+holdDateTime1.toLocaleString("sv-SE")
msg.ReportStr += "\nholdDateTime1:" + holdDateTime1
msg.ReportStr += "\nTimestamp1: " + holdDateTime1.getTime();
msg.ReportStr += "\nISO2: " + holdDateTime1.toISOString();

msg.ReportStr += "\nIsDate: " + (holdDateTime1 instanceof Date);
msg.ReportStr += "\nConstructor: " + holdDateTime1.constructor.name;
msg.ReportStr += "\nTime: " + holdDateTime1.getTime();
msg.ReportStr += "\nISO: " + Date.prototype.toISOString.call(holdDateTime1);

let holdDateTime2 = flow.get("HoldDateTime2")
msg.ReportStr += "\nholdDateTime2:"+holdDateTime2.toLocaleString("sv-SE")

msg.ReportStr += "\nTimestamp2: " + holdDateTime2.getTime();
msg.ReportStr += "\nISO2: " + holdDateTime2.toISOString();

msg.ReportStr += "\nIsDate: " + (holdDateTime2 instanceof Date);
msg.ReportStr += "\nConstructor: " + holdDateTime2.constructor.name;
msg.ReportStr += "\nTime: " + holdDateTime2.getTime();
msg.ReportStr += "\nISO: " + Date.prototype.toISOString.call(holdDateTime2);

There is only these 2 that uses "HoldDateTime1" and "HoldDateTime2"
I don't think it's the actual flow.set() and flow.get() that is the problem.

主要語言
JavaScript
星號
123k
分支
39.3k
平均合併
4 天 15 小時
30 天內合併 PR
238

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

nodejs/node 的其他 Issue

查看 nodejs/node 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。