Local time for text input node using datetime picker

Hi,

Is there any easy way to get a 'text node' set as 'datetime picker' send the output as local time.
Currently I get the output in UTC.
Example:
When I select 14/4/2023 and 10:00 in the ui the output is
14/04/2023, 12:00:00 [UTC+2] (= 1681466400000 = 2023-04-14T10:00:00.000Z)

I would like it to return a timestamp corresponding to 14/04/2023, 10:00:00 [UTC+2].

I guess one way is to put a function before & after the text node to adjust the time but I'm wondering there is a smarter way as the adjust functions would need to take into account summer/winter time.

The moment node?
node-red-contrib-moment

Do you mean that your local timezone is UTC+2, but when you enter 10:00 it is giving 10:00Z?

Are the machine running node-red and the machine running the browser both set to UTC+2?
Are you running node-red in Docker or Home Assistant or something other than a native node-red install?
I think it it possible to override the local timezone in the browser settings, make sure that browser is set to use the system timezone.

Do you mean that your local timezone is UTC+2, but when you enter 10:00 it is giving 10:00Z?
Yes

Are the machine running node-red and the machine running the browser both set to UTC+2?
Yes. Tested with Timestamp>Debug in browser and Date command on Raspberry Pi

I have a native install of Node Red on a Raspberry Pi.
I'm using Safari browser (no time setting) on a Macbook (time set to local time zone, UTC+2)

Thanks, I'll test it but not sure if it can automatically manage the summer/winter time switch (UTC+2 vs UTC+1)

That should not be happening.
Can you try a different browser?

It should as I use it and it does track Summertime for me.

I get the same results over Safari on an iPad.
Over the weekend I'll test with Chrome and directly on the Raspberry, but need local access for that.

The first thing to do here is to find out why the node is returning the wrong time.

Can you post a minimal flow showing the error please so I can test exactly what you are doing.
Are you using the latest version of node-red-dashboard? If not then upgrade that.
If still doesn't work can you post the full output you get when you stop and start node-red in a shell on the pi using
node-red-reload

Here is an example flow.
If I inject a timestamp it will display as UTC in UI but in the debug it will show as the correct local time
If I change in the ui then the debug will show the wrong local time.

I'll update node-red-dashboard over the weekend (currently v3.3.1)

[
    {
        "id": "4d49653279fea87a",
        "type": "tab",
        "label": "test",
        "disabled": false,
        "info": "",
        "env": []
    },
    {
        "id": "58ca500df7734f6a",
        "type": "ui_text_input",
        "z": "4d49653279fea87a",
        "name": "",
        "label": "test",
        "tooltip": "",
        "group": "a095025ac31861a2",
        "order": 2,
        "width": 4,
        "height": 1,
        "passthru": true,
        "mode": "datetime-local",
        "delay": "500",
        "topic": "topic",
        "sendOnBlur": true,
        "className": "",
        "topicType": "msg",
        "x": 290,
        "y": 80,
        "wires": [
            [
                "ac45236ea4df9b23"
            ]
        ]
    },
    {
        "id": "ac45236ea4df9b23",
        "type": "debug",
        "z": "4d49653279fea87a",
        "name": "debug 7",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 460,
        "y": 80,
        "wires": []
    },
    {
        "id": "10eb98c798096036",
        "type": "inject",
        "z": "4d49653279fea87a",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "x": 140,
        "y": 80,
        "wires": [
            [
                "58ca500df7734f6a"
            ]
        ]
    },
    {
        "id": "a095025ac31861a2",
        "type": "ui_group",
        "name": "Test",
        "tab": "76c928cd.92de08",
        "order": 5,
        "disp": true,
        "width": "6",
        "collapse": false,
        "className": ""
    },
    {
        "id": "76c928cd.92de08",
        "type": "ui_tab",
        "name": "Test",
        "icon": "dashboard",
        "order": 1,
        "disabled": false,
        "hidden": false
    }
]

Same here, is this a bug of the UI node? Maybe you can manually changing it via function node.

output_datepick_01

Exactly the issue! And nice way to show with a video!

@dceejay are you able to comment on this? It does appear to be sending the incorrect time, and it isn't the 1970 DST issue, or doesn't appear to be anyway.

When using the text input in date time mode it relies on whatever rendering the browser and OS decide to give you - you will get different widgets depending on your browser or device. If you click on the returned value in the debug it will show the time in various different formats including UTC, local time, epoch time etc.

It isn't that. We are on UTC+1 at the moment, and if I select 15/04/2023 20:40 (which is 19:40 UTC) then in the debug node I see
image

So it is showing 20:40Z, or 21:40 UTC+1, instead of 19:40Z or 20:40 UTC+1

I am seeing that in Chrome and FF.

Yes. The date time-local input option doesn’t seem to handle things like that.

That doesn't seem to cover it, as far as I can see. This flow has a datetime picker using the node, and also a native html version using datetime_local in a ui_template.
The node returns an epoch timestamp, which I convert to an ISO string for display in a debug node and the ui_template returns it as a string. The ui_template gets it right, but the node is an hour out.

[{"id":"58ca500df7734f6a","type":"ui_text_input","z":"4d49653279fea87a","name":"","label":"text input node","tooltip":"","group":"a095025ac31861a2","order":2,"width":4,"height":1,"passthru":true,"mode":"datetime-local","delay":"500","topic":"topic","sendOnBlur":true,"className":"","topicType":"msg","x":160,"y":80,"wires":[["64f9d1a5d809e2f7"]]},{"id":"ac45236ea4df9b23","type":"debug","z":"4d49653279fea87a","name":"Text input node","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":540,"y":80,"wires":[]},{"id":"2f8334f4.cefd7c","type":"ui_template","z":"4d49653279fea87a","group":"a095025ac31861a2","name":"datetime_local in ui_template","order":5,"width":0,"height":0,"format":"<input ng-model=\"me.item.value\" type=\"datetime-local\"\n  ng-change=\"send({payload: me.item.value})\">","storeOutMessages":true,"fwdInMessages":true,"resendOnRefresh":true,"templateScope":"local","className":"","x":200,"y":140,"wires":[["703b20675f7f4e7b"]]},{"id":"703b20675f7f4e7b","type":"debug","z":"4d49653279fea87a","name":"ui_template","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":530,"y":140,"wires":[]},{"id":"64f9d1a5d809e2f7","type":"function","z":"4d49653279fea87a","name":"toISOString()","func":"msg.payload = new Date(msg.payload).toISOString()\nreturn msg;","outputs":1,"noerr":0,"initialize":"","finalize":"","libs":[],"x":350,"y":80,"wires":[["ac45236ea4df9b23"]]},{"id":"a095025ac31861a2","type":"ui_group","name":"Test","tab":"76c928cd.92de08","order":5,"disp":true,"width":"6","collapse":false,"className":""},{"id":"76c928cd.92de08","type":"ui_tab","name":"Test","icon":"dashboard","order":1,"disabled":false,"hidden":false}]

OK - have pushed a possible fix to master branch. (not on npm)

Does that count as a breaking change? It appears to have been like that for a long time.