Maybe a handy *time stamp* subflow

This node generates a time stamp when it gets an input.

The incoming payload is saved and used on the second output.

The node generates a local time time stamp and presents it to the three outputs as:
1 - as text which can be used in a text file.
2 - as msg.topic in the same format as output #1
3 - as text which is compatible to be used in a file name. (Striped : from the output)

Yeah, it won't fix every need, but it could be handy.
Rather than having to constantly use the moment node - which I used - and set the output style.

This is a simple addition to what the node does and how it can be used.

[{"id":"5828ee16.d65a","type":"subflow","name":"Time Stamp","info":"","category":"","in":[{"x":80,"y":100,"wires":[{"id":"38fcac0b.21d234"}]}],"out":[{"x":780,"y":100,"wires":[{"id":"ae0623ca.fcb5e","port":0}]},{"x":780,"y":150,"wires":[{"id":"e0f25625.f2aee8","port":0}]},{"x":780,"y":200,"wires":[{"id":"8897711f.686e08","port":0}]}],"env":[],"color":"#FF8888","outputLabels":["For logging use","msg.time","For filename use"],"icon":"node-red/timer.svg"},{"id":"ba266090.d5a6","type":"function","z":"5828ee16.d65a","name":"Time Stamp","func":"var d = new Date().toLocaleString();\nmsg.payload = d;\nreturn msg;","outputs":1,"noerr":0,"x":310,"y":100,"wires":[["ae0623ca.fcb5e"]]},{"id":"ae0623ca.fcb5e","type":"moment","z":"5828ee16.d65a","name":"","topic":"","input":"","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-DD-MM HH:mm:ss","locale":"en_AU","output":"","outputType":"msg","outTz":"Australia/Sydney","x":500,"y":100,"wires":[["8897711f.686e08","238422be.bf932e"]]},{"id":"8897711f.686e08","type":"string","z":"5828ee16.d65a","name":"","methods":[{"name":"replaceAll","params":[{"type":"str","value":":"},{"type":"str","value":""}]},{"name":"replaceAll","params":[{"type":"str","value":" "},{"type":"str","value":""}]}],"prop":"payload","propout":"payload","object":"msg","objectout":"msg","x":550,"y":200,"wires":[[]]},{"id":"238422be.bf932e","type":"change","z":"5828ee16.d65a","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":330,"y":150,"wires":[["e0f25625.f2aee8"]]},{"id":"38fcac0b.21d234","type":"change","z":"5828ee16.d65a","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":170,"y":100,"wires":[["ba266090.d5a6"]]},{"id":"e0f25625.f2aee8","type":"change","z":"5828ee16.d65a","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":550,"y":150,"wires":[[]]}]
1 Like

@Trying_to_learn Andrew, please edit your post - this is a subflow not a node
Secondly you can create any of those formats with the moment node

1 Like

...or node-red-contrib-simpletime

Errr, no.

I was going to reply to that in the other thread.

I can't do that with the moment node as it wants a timestamp input to work.

This doesn't require/expect a timestamp input.

Thanks @Paul-Reed but that really looks complicated to get an output like what this subflow gives.

I admit/accept I did kind of overlook simpletime compared to moment. I guess it is down to how I see things.

I just looked at it and though it can give you a heap of options that would entail a lot of concatenating to get the three outputs the subflow gives.

I may keep it in mind for future use. I did have this thought in the back of my mind about another node to do this but just forgot about simpletime.

1 Like

As I said in the other thread, in the moment node you can select the input to be msg.payload OR it can be a time stamp.

1 Like

Can you give me an example of what's more complicated in simpletime than your sub-flow?
I've tried to make it as usable as possible, but if there is a problem, maybe it can be improved...

I am sorry. Yeah, I see there is that option. But....... As I think I said I just felt like making a more generic timestamp node as I have a lot of function nodes doing this function in a few different (and sometimes annoying) ways.

This gives me 3 different formats.

I get that it could be done other ways. I just wanted to go through the motions of writing a node (subflow) to try and improve my understanding of Node-Red.


I am sorry, I didn't mean it as a put down to your node.

I guess it is just a very different way of doing it and when I was doing it, I had overlooked the simpletime node and worked with what I saw.

Just another reason - again: not a put down to your node - is that I get 2 different formatted output easily. (The second with the string node to replace remove the :

Doing it with your node I would need a function node after it and then construct what is needed with all the sub-messages.

In the bigger picture, I guess it isn't that much more.
But then to get the second format message I would have to make a second message, or put it through the string node.

Not normally. Just a template node is usually needed to create bespoke time formats.

If you need additional formats - simply add another template node.
It's a very lightweight solution.

But hey, it's all good fun creating your own solutions :grin:

Not so. From the help:

If input is "timestamp" or a JS datetime object or a string that Moment.js can resolve (with the help of moment.parseFormat). It will be processed as normal.

You can pass in any string the that underlying moment node understands. The link is to the docs.

(I must be rewriting the book of stupid, but I shall reply all the same)

All I am reading from what you are saying is that somewhere in the input there must be a timestamp of some sorts.

What if the incoming message has nothing to do with time?

Again thanks Paul.

Alas the template node is also one of those nodes into which I have had little use/need/experience so it was overlooked.

I shall try to store that in the not too reliable memory for future reference.

1 Like

Urm, well it is a node for translating date/time. If you feed it something that cannot be understood as a date/time value, it can't do anything useful - so it doesn't!

I have thought about making it use the current date/time if it gets something it can't understand but that is fraught with issues. It would mean that, if someone gave it something that they thought was a date but had an error, they would still get a valid output which could be pretty disastrous. Garbage in should always result in an error. Or, in this case, a warning and a blank output so that you can check for that in your flows if you like.

And I fully understand that. I just made the subflow (which is a node in the bigger picture) to create an output so if the user wants to timestamp a message as it passes they can, easily.

I agree @Paul-Reed 's node would (probably) have been easier to implement, but as you can see I just posted that my scope hasn't covered the template node either so that is two unknown nodes used and why I didn't.

Anyway, thanks again.

I think we'd better call it a day on that. I seem to have this ability to drag things on way past their "best before" date.
(pun kind of intended.)


@Trying_to_learn, to add a timestamp to a message I used to use the thethingbox-node-timestamp node. Unfortunately, it gives only a text string in ISO-8601 format, not a unix timestamp. Since the development of the change node I have been using that instead. Configured as shown, it gives both the unix time and a formatted string.


Yeah, thanks.

But I think @Paul-Reed 's mentioning of simpletime node is just as good if not better as it offers more options than just the ISO formatted time stamp.


1 Like

At the cost of having to install a non core node.
(Hardly a big problem, but just a little less transportable across systems)

1 Like

if you take a non existing as input in moment it creates a time stamp that you assign to topic output. (formated as you like) A msg.payload from a node before moment will be pased through moment. As a result you get an object with time in topic and your payload.

I've just found a bug in the flow/node/sub-flow.

Nothing too spectacular, but it can be annoying with date formats.

This isn't the best way to roll out the upgrade, but I remember having problems with sub-flows and the in and out nodes not being taken along with the code.

Simple fix:

Delete the function node which gets the time stamp and replace it with a change node that sets the payload to timestamp.


Then the output format problem I found should be resolved.