Intermittently corrupted JavaScript Date output in Node-RED Function node
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 45/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, node.js
- Lĩnh vực
- backend
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- JavaScript
- Star
- 123k
- Fork
- 39.3k
- Merge trung bình
- 4 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 238
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của nodejs/node
-
util: parseArgs() treats a `-` inside a short option group as the `--` terminatorCó thể đã có người làm @yohannesjoya đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
http2: content-encoding is incorrectly listed in kSingleValueHeadersCó thể đã có người làm @inoway46 đã nhận 2 ngày trước. Đang mởconfirmed-bug http2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
nodejs/node#67151 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
util.parseEnv and --env-file keep a leading UTF-8 BOM in the first keyCó thể đã có người làm @helmipradita đã nhận 4 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
node:internal/inspector/network_http: `TypeError: Missing dataLength` in event when response uses `setEncoding()`Có thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
nodejs/node#66551 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Docs] `process.loadEnvFile()` does not document behaviour when variables already existCó thể đã có người làm @Sepandard đã nhận 38 ngày trước. Đang mởdoc
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
riverqueue/river#1576 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue help wanted
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
modrollstudio/Modroll-Studio-Website#80 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add tests for CSV email parsingĐang mởgood first issue help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
mafzalkalwardev/mailforge#21 ·
-
good first issue help wanted
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100