Timestamps...... Sorry

General
1

I've been messing about with things and wanted a "human readable" time stamp on stuff.

I've seen reference to the J: now() thing which is handy to put in, as I just add a change node and set msg.time to J: now() and I get a nice time stamp.

What I didn't realise is it is Zulu time.

Yeah, there is the simpletime node. Bit of overkill I think.

I could use it. But I just want a quick and easy way to just time stamp a message for later diagnostic stuff, and I would prefer human readable.

Thanks in advance.
(as you may have noticed: I'm back to the NR projects.)
(It is just upsetting that as hard as I have tried: I've forgotten things since the last time.)

2

So to get to the point, you want a node that gives you a human readable date.

But not the simpletime node that reportedly does just that?

If a node that the author describes as "extremely lightweight" is overkill for your needs, can you describe why? As I imagine other nodes with the same functionality are likely to fail your criteria as well.

3

OK, sorry.

I was reading on another thread that it wasn't.

I don't/didn't have it installed so couldn't comment.

(See new post on the install of simpletime)

So the J: now() is strictly Zulu time?

Ok.

4

You should really be doing as much date/time processing as possible in UTC/Zulu/GMT since it avoids the many issues that local times bring with them. Such as daylight saving switches for example.

It really does make life a lot easier if you do your processing in UTC then convert to local time on display.

Also note that node-red-contrib-moment contains a humanizer node as well as the main moment node which will give you human readable output. While this is certainly not lightweight under the covers, it is certainly simple from a flow designers perspective.

5

This is only for short term debugging.

There are a few more gremlins in the system and I want to stamp the messages with a human readable time stamp so I can see when these erroneous things are happening.

I hope they life of this bit of the flow is less than a month.

This is a very cut down example of the flow: Suffice to get the idea.

[{"id":"ea68388a.cb83","type":"inject","z":"baf80d2f.6bd538","name":"","topic":"temp/external","payload":"test","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":190,"y":3850,"wires":[["6247db4b.10bcbc","8f4a7a76.a39ee"]]},{"id":"8f4a7a76.a39ee","type":"change","z":"baf80d2f.6bd538","name":"Time","rules":[{"t":"set","p":"time","pt":"msg","to":"$now()","tot":"jsonata"}],"action":"","property":"","from":"","to":"","reg":false,"x":370,"y":3850,"wires":[["d6ba8a8.e508878"]]},{"id":"d6ba8a8.e508878","type":"function","z":"baf80d2f.6bd538","name":"","func":"var topic = msg.topic;\nmsg.otopic = topic;\nvar res = topic.replace(\"/\", \"-\");\n\nmsg.topic = res;\n\nreturn msg;","outputs":1,"noerr":0,"x":550,"y":3850,"wires":[["43cf92ab.284474"]]},{"id":"43cf92ab.284474","type":"debug","z":"baf80d2f.6bd538","name":"","active":false,"tosidebar":true,"console":false,"tostatus":true,"complete":"true","x":690,"y":3850,"wires":[]}]

00:23 local time.

System shutting down for "today".

6

In programming, it is all to often the "simple" things (for users) that are the hardest to program!

1 Like
7

So are you ok now or do you need further help? If you need further help what are you currently getting in the debug and what do you want to see?

8

Seconding the recommendation to play with the moment node (to hopefully counter any impression of bias on the part of other posters... for... reasons... :wink:) If there was ever a candidate for a contrib node to be rolled up into the core set, I'd argue for moment and dashboard.

1 Like
9

:shudders: Nooo! :wink:

Quite apart from the fact that they are managed by different people :cough: moment would have to be combined with uibuilder if anything!

They are each complex enough to be kept separate though thanks.

10

I assume that J: here means JSONata. According to the documentation, the $now() function supports optional arguments for formatting and timezone, but I have not been able to get this working. Perhaps we are dealing with an early/partial version, or I am messing up.

11

Morning all.

(6 hours of sleep later)

Ok. moment will be looked at.

Yes, you are correct.

If you look in the small flow I posted it will show you how to do it.

I didn't know of the options.

I was searching for how to get the time and found a few threads.
Someone said use the J: now() to do it. So I tried it and it worked.

Yeah, shame on me. Should 'a' looked a bit harder for docs on extras stuff you can stick on it.

12

To timestamp a message for humans you could alternatively use a function node with:

msg.time = new Date().toLocaleString()
return msg;
1 Like
13

I am also looking for where the "options" for the J: $now() (forgot the $ in previous posts - sorry.) but that looks just as easy.

Appreciated.

Oh, not to be picky but.....

That needs a terminating ; - yeah? :wink:

14

Adding semicolons at the end of lines is optional most of the time as Javascript figures it out automagically!

1 Like
15

Hopefully still on topic, the JSONata $now function does not behave the same way in the change node as in the exerciser on the website.

In the exerciser:
$now() => "2019-01-29T21:10:52.783Z"
$now('[H01]:[m01]:[s01] [z]', '-0500') => "16:09:44 GMT-05:00"

In the change node:
$now() => "2019-01-29T21:10:52.783Z"
$now('[H01]:[m01]:[s01] [z]', '-0500') => Invalid JSONata expression: Argument 1 of function "now" does not match function signature

I dimly remember an earlier discussion of which version of JSONata is used in NR and what limitations it has, but I can't find it. Can we get an update on this?

16

Node-RED 0.19.5 has JSONata 1.5.4

Node-RED 0.20.0-beta.4 has JSONata 1.6.4 (the latest at the time of writing)

17

Thanks!

I'll dig in and see if that explains anything. It's a good excuse to finally start playing with the beta.

18

A quick look at the changelog on GitHub says that this feature was introduced with v 1.6.1. Problem probably solved. Perhaps someone already running the beta could confirm.

19

Beta works fine

1 Like
20

Others have already stated strongly that all processing should be done on GMT timestamps -- which is solid advice. Save the conversions to human-readable for the UI...

BUT, I'm thinking that some confusion (and complexity) could be avoided if the debug sidebar would show human readable timestamps using the *browser's timezone", not Zulu time? Whether that is just another "setting" or one of the "modes" that would appear while toggling through the display in the sidebar, well that's another question...

Currently, when a timestamp is shown in debug and I click on it, the display cycles between:
1548949510139 - internal timestamp
2019-01-31T15:45:10.139Z - zulu time
0x168a495d7fb - hexadecimal

Maybe just add another for local (browser) time?