You don't seem to be running the same flow as I am, as both my fields are time and you seem to have a date and a time.
and I got the same result when I did the same
In our locale we are currently at UTC +00.00 therefore there is no reason to apply an artificial adjustment (DST/BST) to any time. What appears to be happening is that the node is believing that we are still in BST when our clocks will display a time which is one hour ahead of UTC and is applying the adjustment to the time which is output. In your case the node is adding the 5 hours that you are behind GMT
I did update the Dashboard to 3.2.3
I am not running in docker or anything similar, and Date in a terminal shows
Sun 27 Nov 11:54:41 GMT 2022
I see the same thing in multiple browsers on multiple machines so I am out of ideas on why it is wrong here but ok across the pond.
It is nothing to do with the specific form in the example, as it behaves the same with just a form with a time field and nothing else.
I'm actually running it on a Mac, but I put it on a Pi and the results are the same. I am using a browser on my Mac to go to the dashboard running on the Pi but that also gives the same correct results.
We need one or two people in other timezones to test it. I know someone I'll contact and have them test it.
Not the same as being in another timezone but...
With my Raspberry Pi timezone set to London (ie UTC), browser on a PC
date shows Sun 27 Nov 14:14:12 GMT 2022
Put 00:00 in start time, debug shows 1969-12-31T23:00:00.000Z
sudo raspi-config, change timezone to Asia / Colombo,
Reboot, load NR (same PC, different browser)
date shows Sun 27 Nov 19:41:12 +0530 2022
Put 00:00 in start time, debug shows 1969-12-31T23:00:00.000Z
ie the form ignores the server timezone and subtracts 1 hour from the input.
I know, that's not what @zenofmud sees
It looks like it applies the browser's timezone (0 for me, -5 for zenofmud) and a bit more for luck.
I'm running as an Add-on to Home Assistant, within VirtualBox on Linux Mint. My UI is running on a Windows 11 laptop
I have submitted an issue Form Time picker gives incorrect time Ā· Issue #787 Ā· node-red/node-red-dashboard Ā· GitHub
Tested here as well. Entered 17:03
NR running on a RPi4, using Chrome browser on my mac, same result if running Chromium browser on the RPi directly
1 Like
16:03Z is correct for local time UTC+1. So far it only seems to be those on UTC that see the problem.
Would the fact that DST in the UK started in 1972 have any bearing on the ISO timestamp output for a 1970 date?
From Feb 68 to November 1971 DST was all year round also.
Ah, good point, I think we have been here before. I think there is an error in the DST rules that make Jan 1970 appear to be in DST. I can't remember what the fix is.
Yes, if I have
msg.payload = new Date(0)
and feed that into a debug node it shows
Thu Jan 01 1970 01:00:00 GMT+0100 (Greenwich Mean Time)
So it thinks that the timezone is GMT+1
So isn't the error therefore that the date returned by the Time Picker should be today's date and not 1 Jan 1970?
It now seems I can't make any more replies for 2 hours
Moment seems to format the correct time though.
$moment("1970-01-01T16:01:00.000Z").format("HH:mm:ss")
output
17:01:00
Umm, the input is 16:01 and the output is 17:01, so same problem
The 16.01 ISO converted to milliseconds is correct. it would probably be better if the output were in milliseconds. Saves any confusion and the developer can convert to what ever zone they wish.
@Buckskin the 16:01 ISO is in utc not GMT, so is confusing, but correct. it just needs converting to correct time zone. As said above outputing in milliseconds would sort any confusion.
Can you explain what you mean by that?
The is timestamp 1970-01-01T16:01:00.000Z converted to milliseconds is 61260000 which is 17.0166666667 hours. Using $toMillis()
