time zones for inject nodes

[Andy Stanford-Clark]

The "at a certain time" options in the inject node use the time settings of the server where your node.js is running with nodeRED in it.

Increasingly, we're deploying flows to "the cloud", with hosts (a) in another (known) time zone, or (b) in an unknown time zone (with some cloud hosts it's sometimes hard to know where the server is domiciled).

I need to inject at message at 10.00am UK time.

My suggestion would be an option in the settings file of nodeRED so you can either:
 specify a time zone offset (i.e. relative to the time that the server thinks it is), to solve scenario (a),
 or a fixed time zone (maybe just force UTC ??) to solve the less-likely scenario (b).

It would be good if the timestamp you generate from
 new Date().toString()
could also reflect this (I'm not sure what support there already is in JavaScript to help with this, but I want it to "just work" in nodeRED ;) )

Andy

[Max Hadley]

Andy,

Some thoughts, in no particular order:

• The graphical IDE should probably show the current time & timezone of the server (instance) hosting node-RED
  
• When creating a flow, it is possible that I want a thing to happen at any or all of the hosting server timezone, UTC, or some other timezone (not necessarily the IDE timezone)
  
• There needs to be a way of specifying if daylight saving/summer time should be applied or not to these times
• Time & date strings should generally include the timezone

Overall, I have a preference for doing everything 'under the hood' in UTC and converting to local time only for display (but which 'local'?)

This is not a trivial issue and it demands careful thought!

Max

[Andy Stanford-Clark]

I agree with what you say, but think a simple solution would fix 80% of the use cases... then we can think more about how to elegantly implement the more complicated scenarios

[Dave C-J]

Andy

a msg.payload = new Date().toLocaleString(); in a function should report it as per the server time  eg 

Sun Sep 21 2014 20:31:23 GMT+0100 (BST)

but yes more thought to make this easy/obvious/transparent does need to be applied.

[Andy Stanford-Clark]

Fixed this by doing
export TZ=Europe/London
before I started nodeRED

#thatwaseasy :)

[Corn98]

Hi Andy,

I have the same problem in function nodes, offset is always 0 even though I came from Italy (so it should be  -60 minutes with  getTimezoneOffset() js method).

Where do you set TZ variable? In setting.js?

Thanks in advance for the help. 

Corn

[Hugo Desmeules]

Sure!

process.env.TZ = "Europe/London"; in settings.js works.

[lorenzo cornaro]

Hi Hugo, 

Thanks for the reply. But What is the property of module.exports where to set the variable? For example, 

module.exports = {

    uiPort: process.env.PORT || 1880,

    ....

I tried to set it outside of the module.exports object but It doesn't works.

Thanks again for the help,

Corn

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/FOHU7kvqeTg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/8d384c71-2812-42a4-8344-2dc76f49bd98%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Julian Knight]

You don't need it in the exports part, try adding before there.

To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

[Corn98]

Hi Julian, 

thanks again for this help too! 

Anyway I tried to set it before the module.exports but it doesn't work for me. Pratically it's the first line of the setting.js:

/**

 * Copyright 2013, 2016 IBM Corp.

 *

 * Licensed under the Apache License, Version 2.0 (the "License");

 * you may not use this file except in compliance with the License.

 * You may obtain a copy of the License at

 *

 * http://www.apache.org/licenses/LICENSE-2.0

 *

 * Unless required by applicable law or agreed to in writing, software

 * distributed under the License is distributed on an "AS IS" BASIS,

 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 * See the License for the specific language governing permissions and

 * limitations under the License.

 **/

// The `https` setting requires the `fs` module. Uncomment the following

// to make it available:

//var fs = require("fs");

process.env.TZ = "Europe/Rome";

module.exports = {

    // the tcp port that the Node-RED web server is listening on

    uiPort: process.env.PORT || 1880,

...

Do you see something weird or wrong?

Corn

[Zenofmud]

did you add:

     env: process.env,

to functionGlobalContext so you have:

    functionGlobalContext: {

         env: process.env,

         os:require('os'),

        // bonescript:require('bonescript'),

        // jfive:require("johnny-five"),

        // j5board:require("johnny-five").Board({repl:false})

    },

(mind the commas!)

Paul

On Mar 1, 2018, at 2:00 AM, Corn98 <jmaco...@gmail.com> wrote:

process.env.TZ = "Europe/Rome";

[Colin Law]

On 1 March 2018 at 11:17, Zenofmud <zeno...@zenofmud.org> wrote:
> did you add:
>
> env: process.env,
>
> to functionGlobalContext so you have:
>
> functionGlobalContext: {
> env: process.env,
> os:require('os'),
> // bonescript:require('bonescript'),
> // jfive:require("johnny-five"),
> // j5board:require("johnny-five").Board({repl:false})
> },
>
>
> (mind the commas!)

Hoist with your own petard I think :)

Colin

> Paul
>
> On Mar 1, 2018, at 2:00 AM, Corn98 <jmaco...@gmail.com> wrote:
>
> process.env.TZ = "Europe/Rome";
>
>

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---

> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/1BF3B479-314F-4EA4-BD74-77179C1627F7%40zenofmud.org.

[Zenofmud]

oops, Colin you are right it should be:

    functionGlobalContext: {

          env: process.env,

         os:require('os’)    <====== note comma removed as it is the last item - i.e. the rest are comments

        // bonescript:require('bonescript'),

        // jfive:require("johnny-five"),

        // j5board:require("johnny-five").Board({repl:false})

    },

What’s funny is that with the extra comma, on my mac, it doesn’t flag it as an error and works fine.

[Zenofmud]

if I was to do this:

    functionGlobalContext: { 

os:require('os')

env: process.env,

// bonescript:require('bonescript'),

        // jfive:require("johnny-five"),

        // j5board:require("johnny-five").Board({repl:false})

    },

then at startup NR fails with:

Error loading settings file: /Users/Paul/.node-red/settings.js

/Users/Paul/.node-red/settings.js:154

env: process.env,

^^^

but adding the comma on the ‘os' line with out removing it on the ‘env’ line and it does not flag it (which is nice).  

[Colin Law]

Yes, I had noticed that. It seems that a line such as
msg.payload = {a: 1, b:2,};
does not even flag a warning in a function node, which suggests it may
be legal javascript.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/7E34E17E-AA7A-4CA1-A9C1-6C3E9E523EAC%40zenofmud.org.

[Corn98]

Hi Paul,

I added " env: process.env, " to functionGlobalContext  and  I set "process.env.TZ" outside module.exports as suggested, but it doesn't change nothing, offset is always 0 (I tryied also getTimezoneOffset() to confirm that)... what's more if I try to do " msg.payload=context.global.env.TZ; " in a function node msg.payload is equals to Europe/Rome. 

Where am I wrong in setting up this variable? Have you some ideas? 

If you have time and if you want, I could try to send you my setting.js.

Hear you soon and thanks for the help!

Corn

[Zenofmud]

If you access the env.TZ you will get the string you set it to.

The question is what are you trying to do?

-- 
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
--- 

You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.

To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.

To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/eaa5b145-33c1-4c2c-9d72-b933b1e7c8df%40googlegroups.com.

[Colin Law]

Good point Zenofmud. @Corn98 you said you were using
getTimezoneOffset(), show us the section of code where you are doing
that.

Also what hardware and OS are you running node-red on?

Colin

> https://groups.google.com/d/msgid/node-red/70FAF84A-D6EB-44A4-8DFD-39518B765175%40zenofmud.org.

[Corn98]

I'm trying to set the right timezone in Node-RED because I always get a delayed date of an hour.

I just used getTimezoneOffset() to confirm what I thought,  but in the code that I'm trying to write I convert milliseconds in dates using "new Date(ms)".

I'm running Node-RED on IoT2040 of Siemens with system and hardware clock set rightly according to my timezone. 

Hope that this info are enough.

Corn

[Colin Law]

What do you see in the debug window if you do
msg.payload = new Date();
return msg;

Colin

> https://groups.google.com/d/msgid/node-red/6f937670-4486-4532-b888-056b7ae85dde%40googlegroups.com.

[Corn98]

Hi Colin,

Sorry for the delay but yesterday in Italy was 6 p.m. and I have to left work place. Now I'm back and I try to do what you suggested, that's the result:

Local hour: 8:52

for "new Date()" payload is worth: 2018-03-02T08:52:45.200Z

for "d=new Date(); d=d.getTime()" payload is worth: 1519980765197

I added the milliseconds because if i try to convert them in NR dashboard in a template node in this way:

<script>

scope.$watch('msg', function(msg) {

    if (msg) {

        

        var d=new Date(msg.payload)

        console.log(d);

    }

});

    

</script>

the result is: Fri Mar 02 2018 09:52:45 GMT+0100 (ora solare Europa occidentale)

Corn

[Colin Law]

It is interesting (if I understand correctly) that you are seeing the
same actual time in node red (08:52 GMT) and in the browser (09:52
GMT+1) and both are not the correct time.
The code in the template is run in the browser so is nothing to do
with settings.js, node-red or node.js. The code

var d=new Date(msg.payload)
console.log(d);

Will get the date/time from the machine running the browser. If you
are running the browser on the same machine as node-red then it
suggests the basic problem is with the machine OS or settings, not
with node-red.

Perhaps the time in the Siemens device is set incorrectly, so it is
set to 09:52 GMT+1 which is the same as 08:52 UTC.

Colin

> https://groups.google.com/d/msgid/node-red/69232375-74bc-48dd-8e37-e7276383a828%40googlegroups.com.

[Corn98]

Hi Colin, 

Glad that you understand my problem! 

I'm running NR in a browser on a different machine than that one where is installed. I have the siemens device in the same LAN of my laptop and I can run NR pointing to "Siemens device's IP address:1880".

Both are correctly set on right timezone (laptop surely, Siemens device at local hour: 14:30 it displays: Fri Mar  2 14:30:13 UTC 2018).

I tried to set one hour less in Siemens device however in the browser time is correct but not in NR. Maybe should be it display UTC+1 like in the image below?

In that case I have to wait the TZ support in Siemens device probably.

Corn

[Colin Law]

On 2 March 2018 at 13:47, Corn98 <jmaco...@gmail.com> wrote:
> Hi Colin,
>
> Glad that you understand my problem!
>
> I'm running NR in a browser on a different machine than that one where is
> installed. I have the siemens device in the same LAN of my laptop and I can
> run NR pointing to "Siemens device's IP address:1880".
>
> Both are correctly set on right timezone (laptop surely, Siemens device at
> local hour: 14:30 it displays: Fri Mar 2 14:30:13 UTC 2018).

What displays 14:30 UTC? You mean a display on the Siemens device or what?

>
> I tried to set one hour less in Siemens device however in the browser time
> is correct but not in NR. Maybe should be it display UTC+1 like in the image
> below?

When you say changing the Siemens time changes the display in the
browser on the laptop is that in the node-red dashboard running the
ui_template that you posted earlier? That should not be affected by
the time in the Siemens. If you open the node-red flow editor on the
laptop and look in the debug window each entry there shows a timestamp
at the top that should be in (laptop) local time. What is that
showing?

Colin

[Corn98]

If i run command prompt "date" in Siemens device (i established a ssh connection with PuTTY) it displays "Fri Mar  2 14:30:13 UTC 2018"  at local hour 14:30.

The timestamp in the debug window is correct to my local hour because it is based on that set in Siemens device. But if I run getTimezoneOffset() in flow editor, offset is 0, instead in NR dashboard it returns -60, rightly.

Pratically hour is right but not the offset, because Siemens device has the right hour but it doesn't take account of TZ, so when I bring any dates from NR to browser on laptop, they are an hour more.

Hence I have to wait the TZ support in the next version of the image of the Siemens device.

For now I will arrange myself with a variable where is set the right offset.

Thanks again for the help Colin!

Corn

[Colin Law]

On 2 March 2018 at 15:36, Corn98 <jmaco...@gmail.com> wrote:
> If i run command prompt "date" in Siemens device (i established a ssh
> connection with PuTTY) it displays "Fri Mar 2 14:30:13 UTC 2018" at local
> hour 14:30.

OK, that is the fundamental problem, the Siemens device is not set up
to use your local timezone. A bit of googling suggests that device
does not in fact support timezones.

>
> The timestamp in the debug window is correct to my local hour because it is
> based on that set in Siemens device. But if I run getTimezoneOffset() in
> flow editor, offset is 0, instead in NR dashboard it returns -60, rightly.

No, the timestamp in the debug window (above each item) comes from the
browser (I think) not from node-red. It is correct because the laptop
is set to the correct timezone. When you run getTimezoneOffset that
is not running in the browser it is running on the Siemens device and
so it correctly says zero (since the timezone in the Siemens is UTC).

My suggestion is to write your flow taking into account the fact that
the Siemens timezone is UTC, and manually adjusting the time if you
need to get to local time. Use a global context variable for the
timezone offset and then you can adjust in one place if at some point
the Siemens device starts using TZ correctly. Remember though that
any code you run in a ui_template is run in the browser and therefore
will have access to the timezone.

The only thing I don't understand is why node.js does not take notice
when you set TZ in settings.js. I presume you are not using an
ancient version of node.

Colin

> --
> http://nodered.org
>
> Join us on Slack to continue the conversation: http://nodered.org/slack
> ---
> You received this message because you are subscribed to the Google Groups
> "Node-RED" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to node-red+u...@googlegroups.com.
> To post to this group, send email to node...@googlegroups.com.
> Visit this group at https://groups.google.com/group/node-red.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/node-red/fc43057b-fe9c-4547-a368-11db41902c61%40googlegroups.com.

[Julian Knight]

Note that you don't need to mess with global variables. Simply use an inject or change node to access directly:

[{"id":"282085c3.f7807a","type":"inject","z":"fc7dbb1a.619c18","name":"","topic":"","payload":"$(EDGE_SQL_CONNECTION_STRING)","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":230,"y":340,"wires":[["e038903d.798c9"]]},{"id":"e038903d.798c9","type":"debug","z":"fc7dbb1a.619c18","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":390,"y":340,"wires":[]}]

Just adjust the env var in the inject in the example.