Need help with a sub-flow and dates (sorry folks)

Why are you using a function node to get the date/time when you can use a change node to add a timestamp to the msg?

1 Like

With 60c/dollar conversion rate..... Not just now.

2011 when it was 1:1, maybe......

Where abouts are you? (Just asking)

Because I didn't know I could do that.

I'll look into that now.

Thanks.

Suburbs of Chicago.

Wow! Ok. Been there ........ 5 times.

Only transit alas. Going to Oshkosh.

But I do know an "Ozzie" who moved there way back in the late 80's.

Small world.

(Bit off topic)

That seems to work.

As it is a sub-flow, I keep text copies of these.
I've forgotten how to export the subflow to the clip board?
I do remember there was a problem that the in and out nodes of the subflow weren't included in the exporting.

Don't worry!

Just remembered. Select the node and export. Though I think that has the problem I mentioned associated with it.

Dear all,

I've only just spotted this and nearly missed it. I could have sorted this for you a lot quicker had I known from the title that you were using the moment node :wink:

As my warning states, trying to identify correct dates from locale-specific inputs is a nearly impossible job. Because I am based in the EU (urm well I was until some twats messed things up - apologies for the expletive), I decided to make that the default if the input was ambiguous as it is in this case.

I would note that all of this would be avoided if you used the ISO format for dates (YYYY-MM-DD) instead of locale-specific formats. I adopted that years ago on my PC and in my software (Excel, etc). It sorts naturally as text and completely avoids ambiguity.

So when handling dates and timestamps, here are the foundation rules that I work to:

  • Always use ISO date format where possible (YYYY-MM-DD)

    So that there can be no ambiguity and so that date strings will naturally sort

  • Always work in UTC (Aka Zulu time or GMT) except when displaying to the user

    To avoid weird errors, especially with timezone and daylight savings transitions. It also makes date/time calculations a LOT easier.

  • When needing a string format for timestamps, always use ISO format

    e.g. 2020-03-07T15:27:46.123Z

    These are always unambiguous and easily machine parsed.

  • When specifying decimal seconds in a timestamp, avoid more than 3 decimal places

    MomentJS cannot cope with more and may return strange dates, a problem that I reported but they declined to fix). Memory failed me there. It wasn't MomentJS that was the problem but rather the parsing extension. See the issue here.

Hi Julian.
Yeah, sorry: my bad with the title.

Yes, I do get the idea of using Zulu time, and it is nice if you live near there and not the other side of the world.

Because I am wanting to see times in LOCAL time, I am trying to get a timestamp node that works.

In the node I have the locale set as en_AU and print the time output as YYYY-MM-DD hh:mm:ss

Well, I think the output is actually YYYY/MM/DD:hh:mm:ss and I reformat that to a file friendly format without / or colons.

So when my flow outputs the incorrect date, I'm confused.

When I went to your github page, my post isn't posted/wasn't posted. Which is strange, but I am not fluent with how github works with posts.

Not wanting to flood the thread with repetitive things I'll hold back on posting more again.

That is irrelevant. You don't normally need to see UTC timestamps, as @TotallyInformation said you should always work internally in UTC and convert to local time when you want to display the time. Therefore usually all the timestamp nodes need to be able to do is to convert from a UTC timestamp (in the form of a javascript Date object or as an ISO string) to local time for display and possibly vice-versa. Are you attempting to stick to that convention?

2 Likes

Slight update to all reading:

The original sub flow had a function node to generate the time stamp.

It was suggested I use a change node instead.

I did that and it seems to be more behaved.

So from that:
Is there a problem with the time stamp the function node created compared to what is given with the change node setting the payload to time stamp?

Some stuff to affirm this theory:

Screenshot from 2020-03-08 09-04-18

Code:

[{"id":"81bf6744.e2fca","type":"change","z":"a941e919.4a7d88","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":490,"wires":[["69d34dee.2327ec"]]},{"id":"8b0f2a2d.ac1c2","type":"inject","z":"a941e919.4a7d88","name":"","topic":"","payload":"foo","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":170,"y":490,"wires":[["81bf6744.e2fca"]]},{"id":"69d34dee.2327ec","type":"change","z":"a941e919.4a7d88","name":"TimeStamp","rules":[{"t":"set","p":"payload","pt":"msg","to":"","tot":"date"}],"action":"","property":"","from":"","to":"","reg":false,"x":300,"y":530,"wires":[["d4ea0006.7a56"]]},{"id":"d4ea0006.7a56","type":"moment","z":"a941e919.4a7d88","name":"","topic":"","input":"payload","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-MM-DD HH:mm:ss","locale":"en_AU","output":"payload","outputType":"msg","outTz":"Australia/Sydney","x":490,"y":530,"wires":[["61d6d5f1.136694","90a868bf.d38458","342679c5.96e6de"]]},{"id":"61d6d5f1.136694","type":"string","z":"a941e919.4a7d88","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":540,"y":630,"wires":[["bf6026.2cf297d8"]]},{"id":"90a868bf.d38458","type":"change","z":"a941e919.4a7d88","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":580,"wires":[["f1cf49e4.32faa"]]},{"id":"342679c5.96e6de","type":"debug","z":"a941e919.4a7d88","name":"1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":530,"wires":[]},{"id":"bf6026.2cf297d8","type":"debug","z":"a941e919.4a7d88","name":"3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":630,"wires":[]},{"id":"f1cf49e4.32faa","type":"change","z":"a941e919.4a7d88","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":580,"wires":[["3395b9b.e481046"]]},{"id":"3395b9b.e481046","type":"debug","z":"a941e919.4a7d88","name":"2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"time","targetType":"msg","x":730,"y":580,"wires":[]},{"id":"b6883877.9c4ad8","type":"function","z":"a941e919.4a7d88","name":"TimeStamp","func":"var time = new Date().toLocaleString();\nmsg.time = time;\nmsg.payload = time;\nreturn msg;","outputs":1,"noerr":0,"x":300,"y":710,"wires":[["6657d703.a6a4a8"]]},{"id":"6657d703.a6a4a8","type":"moment","z":"a941e919.4a7d88","name":"","topic":"","input":"payload","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-MM-DD HH:mm:ss","locale":"en_AU","output":"payload","outputType":"msg","outTz":"Australia/Sydney","x":490,"y":710,"wires":[["6d5014b1.2e7024","7d832e19.919f58","b8bdd8fd.618978"]]},{"id":"6d5014b1.2e7024","type":"string","z":"a941e919.4a7d88","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":540,"y":810,"wires":[["4638ff0.73c24"]]},{"id":"7d832e19.919f58","type":"change","z":"a941e919.4a7d88","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":760,"wires":[["749449c5.91cc1"]]},{"id":"b8bdd8fd.618978","type":"debug","z":"a941e919.4a7d88","name":"A","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":710,"wires":[]},{"id":"3e45789d.28fdc8","type":"change","z":"a941e919.4a7d88","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":320,"y":670,"wires":[["b6883877.9c4ad8"]]},{"id":"4638ff0.73c24","type":"debug","z":"a941e919.4a7d88","name":"C","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":810,"wires":[]},{"id":"749449c5.91cc1","type":"change","z":"a941e919.4a7d88","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":760,"wires":[["1063b383.46170c"]]},{"id":"a540d96d.0ba558","type":"inject","z":"a941e919.4a7d88","name":"","topic":"","payload":"foo","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":170,"y":670,"wires":[["3e45789d.28fdc8"]]},{"id":"1063b383.46170c","type":"debug","z":"a941e919.4a7d88","name":"B","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"time","targetType":"msg","x":730,"y":760,"wires":[]}]

Andrew, it should be easy to check out. Create a flow with an inject node connected function node connected to a debug node (set to display complete msg object)

Have the inject set msg.payload to a timestamp.
In the function node have

var d = new Date();
var u = d.getTime();
msg.functiondate = u
return msg

and look at the results.

This is getting way above my skill set.

I am posting here with more information only to try and help people who are smarter than me find the problem.

The change node sending a timestamp seems to be the better way for getting the flow working.

Again I shall state that the whole idea of the sub-flow node is that you can send anything into it and get a message coming out that is the date/time in the ISO format.
YYYY-MM-DD hh mm ss
(correct?)

Yes, there is a provision in the sub-flow to pass messages, but that is for local requirements.
It may be handy for others too.

No...as long as you are comparing apples to apples and not apples to a hamburger.

1 Like

No, that is what the moment node is for not your subflow :slight_smile:

But as I've tried to say, it isn't that easy. It is impossible to be able to send ANY timestamp and have it converted. Unless you also know the input format. MomentJS certainly can't do it, that's why I use a separate package to extend its ability to parse inputs. But even that cannot be perfect as is mentioned in the help information for the moment node.

An example of why it is not possible is that there is no way to know what 02/03/20 means without information on the format of the data coming in.

When I create the time stamp in the function node, with this code:
var time = new Date().toLocaleString();

LOCALESTRING So to me that implies time zone is a given.
Ok, I have been wrong before.

When I use the change node and set the timestamp in there, the flow works better.

So why is there that disparity in what happens?

To me that needs to be explained to me - if someone wants to - because as far as I can take it:
there lies a problem.

Post 23 shows that clearly.

Hi, you don't need to put the toLocaleString() on the end, it is not needed. If you leave it off, you can pass the date object directly out to the moment node and let it convert to the appropriate locale/timezone.

When you add the function, it does indeed use the timezone BUT, it doesn't pass it out to the ongoing msg because locale is expected to be used for display as we've previously said.

Sorry, but we've already done this. You've output an ambiguous date/time, the parse function had to make an assumption which unfortunately for you is the wrong assumption for your use. All avoided by using UTC/ISO.

1 Like

Well,

I'm not understanding it.

I guess I shall just have to live with the ignorance of not knowing. Though I was already doing that before I asked. I just didn't know I didn't know.

Is the key.

Human readable dates are ambiguous when applied across different localities. Computers don't deal well with ambiguity.

While you know the timezone/locality that date is in, the computer doesn't because you haven't told it.

I made the node guess based on where I live. Sadly, you are on the opposite side of the globe I think.

The solution is either to provide the input in an unambiguous format or to pass in the source timezone & locale.

And I fully agree.
Which is why there are time zone things, etc. Locale.... et al.

So I don't get why:
I get a function node and set it up to give the time locally. (Now)
I input that to the moment node and get it to spit out YYYY-MM-DD hh.mm.ss (slight change of punctuation, but I don't think that is really relevant).

I get the wrong output.

However, if I replace the function node with a change node and get it to make the msg.payload the timestamp it works.

You say you have explained it, and I can't/won't dispute that.
I am not understanding it. Be it I am thicker than you gave me credit, or what ever.

The problem has been resolved by using the change node.
Why/how? Can't say. I don't think I am going to get it. Such is life.

That was what I thought I was doing. But again: I am wrong.

I can only do what I understand and know.