I have a function node which starts with
var date = new Date();
The output comes out at 'Zulu time'
I read that the time is the computer time but it doesn't seem to be. I can't see how to fix it
What computer is Node-red running on?
What computer are you viewing the editor from?
And what timezones are each one in?
That happens because that is the default when a JS object containing a date is converted to a string for display, it defaults to ISO8601 format which is always in UTC (AKA Zulu or GMT).
To avoid that, convert to a local date/time string before display.
It's a Raspberry Pi with Timezone set to Europe/London and displays current BST
The PC running the editor is a Windows 11 PC at current BST
Except that everything I've read says that the Date() is the time of the computer running Node-Red and it seems a bit strange that it would go through all the trouble of taking the computer time, checking what timezone it's in and then calculating what zulu time is when 99% of the people want to know the date/time where they are not, potentially, thousands of miles away.
I've fixed it with
var date = Date().toLocaleString('en-GB')
OK so that's similar to my setup but I get this at 12:52 BST:
pi@Pi:~ $ date
Tue 27 Sep 12:51:58 BST 2022
NR var date = new Date() -> debug node shows
Tue Sep 27 2022 12:52:00 GMT+0100 (British Summer Time)
Is your debug output showing the function output or somewhere further down the line?
Can you show us your code?
What does the locale command ion the Pi return?
pi@raspberrypi:~ $ locale
LANG=en_GB.UTF-8
LANGUAGE=
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
The function node stores the date and other parameters into a buffer which then goes to a MQTT node. The output goes straignt to the debug node.
I've discovered if I do
var date = Date()
I get what you get but
var date = new Date()
doesn't use local time
The first thing to remember is that 12:26 UTC and 13:26 GMT+1 are the same time, just displayed in different ways. In a javascript Date, as I understand it, the data is held as the number of milliseconds since 00:00 UTC on 1st Jan 1970 (or whenever, it doesn't really matter). Also in the Date object is a timezone, but this is really just a hint about how to display the time if the calling code asks for it in local time. It doesn't affect the actual time of the object, just how to display it.
The code var date2 = new Date() creates a Date object with the time set to the current time, and the timezone hint set to the local timezone of the device running the code.
The Date constructor called as a function, as in var date1 = Date() returns a string representation of the current date and time. The result is the same as executing var date1 = new Date().toString(). Since the code in the node.warn statement concatenates the Date object with a string it forces the Date to be converted to a string, so for date2 it calls toString, so the result for the two dates is identical.
For the payload display in the debug node, date1 is still just a string so it displays the same as in the first output. For the second it is up to the debug display code (in the browser I think) to decide how to show the time, and it has chosen to display it as UTC. Remember, though, as I said, both the first and second outputs are showing the same time, just displayed in a different way. The moral is, most of the time don't worry about it, just make sure whenever it is displayed to an end user that it is shown in whatever format he wants it.
Oh, and don't use var d = Date()as that gives you a string, which is unlikely to be what you want.
Strange or not, that's what it does.
As you can see, I run my servers in UTC which seems much simpler to me since I'll always be storing and manipulating dates and times in UTC. Only at point of user entry or user display will I use local time.
I've been doing date/time utilities with various languages on and off for nearly 40 years and this comes from long and bitter experience 
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
