Determine tomorrow's day of the month

I'm running Node Red v3.0.2 in a Linux VM

I'm trying to write some code to determine tomorrow's day of the month. One of my goals is to be as lean as possible, as this will run in a small system later. So to avoid adding large contributions, my approach is to get today's time, add 18400000 milliseconds to it (to get same time tomorrow), then get the date for that time. Here's my code:

var today = new Date().getTime();
var nDate = new Date().getDate();

var tomorrow = today + 18400000;
var tDate = new Date(tomorrow).getDate();

node.warn("Today = " + today + ", date  = " + nDate);
node.warn("Tomorrow = " + tomorrow + ", date  = " + tDate);

This worked a few times, but now I'm getting that today and tomorrow are the same:
Today = 1672050837310, date = 26
Tomorrow = 1672069237310, date = 26

The timestamp difference seems OK, but the date returned is not.
Any hints on what I'm doing wrong?

Welcome to the forum @scsirob
The first one is 10:34 today and the second is 15:40 (both today GMT). You can check these at https://www.epochconverter.com/

Recheck your maths there. Something is wrong with that figure.

If you create a time object you can then minipulate as you need
e.g.

msg.payload = {};
const time_obj = new Date(); //create time/date object
msg.payload.OG_time_object = RED.util.cloneMessage(time_obj);
msg.payload.time_milisecond_today = time_obj.getTime(); // us time object to get milliseconds
time_obj.setDate(time_obj.getDate() + 1) // add 1 day to time object
msg.payload.new_updated_time_obj = time_obj;
msg.payload.tomorrows_date = time_obj.getDate(); // get tomorrows date
return msg;
1 Like

using moment

[{"id":"da90eebca55dbd3c","type":"moment","z":"1d77a0662bab21bb","name":"","topic":"","input":"","inputType":"date","inTz":"Europe/Berlin","adjAmount":"1","adjType":"days","adjDir":"add","format":"DD","locale":"DE-de","output":"","outputType":"msg","outTz":"Europe/Berlin","x":860,"y":480,"wires":[["05498e6eb3a39768"]]},{"id":"0c93d93f16d3c3db","type":"inject","z":"1d77a0662bab21bb","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":660,"y":480,"wires":[["da90eebca55dbd3c"]]},{"id":"05498e6eb3a39768","type":"debug","z":"1d77a0662bab21bb","name":"debug 42","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1060,"y":480,"wires":[]}]

Using moment() without installing moment node, using a change node and a JSONata expression

$moment().add(1,"day").format("D")

example flow

[{"id":"0ccc963f1de2b66d","type":"inject","z":"da8a6ef0b3c9a5c8","name":"","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payload":"","payloadType":"date","x":120,"y":660,"wires":[["95f032d857efa5ed"]]},{"id":"95f032d857efa5ed","type":"change","z":"da8a6ef0b3c9a5c8","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"$moment().add(1,\"day\").format(\"D\")","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":340,"y":660,"wires":[["441b83f51eec6037"]]},{"id":"441b83f51eec6037","type":"debug","z":"da8a6ef0b3c9a5c8","name":"debug 116","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":650,"y":660,"wires":[]}]
1 Like

I think the guy just needs to the number of msec in a day correct.

Not according to his first sentence in second paragraph. He also needs to understand you create a time object, then you can manipulate it as long as you do not overwrite or convert its type. For that he does not need any milliseconds.

Do you mean his code will not work as written (with the right msec offset). Why not?

No i mean he does not require milliseconds to get tomorrows date from a time object. But if milliseconds were correct it would work also, obviously.

Agreed, though obviously there is a small possibility of error with the msec approach over the DST boundary (when there are 23 or 25 hours in the day).

Thanks all for the comments.
Duh.... Wrong milliseconds. Need to use 86400000 instead.
The accuracy doesn't need to be in milliseconds. The resulting date is used to iterate through an array that was retrieved from a web API call, with date, time and information entries for each hour. The array is multiple days ahead, with this function I filter just tomorrow's data.

Setting the time object to one day further as @E1cid described also works and is less code, so I will use that. I'm used to writing in C, learning a new language is a bit of a hill for me.

This now works, thanks!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.