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

[Trying_to_learn]

Ok, I have shared a "node" (Sub-flow) recently which has three outputs.
msg.payload that is suitable for use as a file name.
msg.payload that is suitable for use as a path.
msg.time which is suitable for use as a file name.

It works.

Well, it kind of does and kind of doesn't.

I posted it to the forum and didn't get any feedback on a problem so I thought all was good.
But then locally I started to see problems.

Rather than the output being YYYY-MM-DD it was YYYY-DD-MM which is annoying when looking at time lines.

I opened the sub flow and looked at it and was shocked to see when I used the moment node, I had goofed and put YYYY-DD-MM by mistake. (Or so I thought)

I quickly changed the code to YYYY-MM-DD and thought nothing more of it.

Today, I am going through checking things and am still seeing the output as DD-MM.

I have checked two of my 3 Raspies and they are both doing it.

Weirdly the third isn't.

Also the NUC - this machine - is also doing it - wrong format.

To further confuse me, the code is the sub-flow is correct in that it says YYYY-MM-DD
Yet the output isn't. It is YYYY-DD-MM

Thoughts?

Though I haven't circled all the problems - as looking it it a bit harder you can see it is worse than I show - you get the idea.

This is the code for the three machines:

And for total inclusion this is from the NUC:

I'm obviously missing an elephant in the room.

Anyone?

P.S.
I've moved the "subflow" up to the edit level and made a normal flow of it.

For your assistance to helping me understand what is happening:

[{"id":"313e36fb.b31f22","type":"function","z":"8aae5d25.29cda","name":"Time Stamp","func":"var d = new Date().toLocaleString();\nmsg.payload = d;\nreturn msg;","outputs":1,"noerr":0,"x":230,"y":330,"wires":[["caa524bf.b5eb5"]]},{"id":"caa524bf.b5eb5","type":"moment","z":"8aae5d25.29cda","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":420,"y":330,"wires":[["183c417e.5ff80f","2aa29446.e3b18c","44c65d67.898004"]]},{"id":"183c417e.5ff80f","type":"string","z":"8aae5d25.29cda","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":470,"y":430,"wires":[["1d4c891d.8581bf"]]},{"id":"2aa29446.e3b18c","type":"change","z":"8aae5d25.29cda","name":"TOPIC","rules":[{"t":"move","p":"payload","pt":"msg","to":"time","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":250,"y":380,"wires":[["729727c3.bfca3"]]},{"id":"3f32eab6.ff56e6","type":"change","z":"8aae5d25.29cda","name":"Save","rules":[{"t":"set","p":"payload","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":250,"y":290,"wires":[["313e36fb.b31f22"]]},{"id":"729727c3.bfca3","type":"change","z":"8aae5d25.29cda","name":"Get","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload","tot":"flow"}],"action":"","property":"","from":"","to":"","reg":false,"x":470,"y":380,"wires":[["5ed635f.678a64c"]]},{"id":"d8ad12e6.c3e7f8","type":"inject","z":"8aae5d25.29cda","name":"","topic":"","payload":"foo","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":100,"y":290,"wires":[["3f32eab6.ff56e6"]]},{"id":"44c65d67.898004","type":"debug","z":"8aae5d25.29cda","name":"1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":660,"y":330,"wires":[]},{"id":"5ed635f.678a64c","type":"debug","z":"8aae5d25.29cda","name":"2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"time","targetType":"msg","x":660,"y":380,"wires":[]},{"id":"1d4c891d.8581bf","type":"debug","z":"8aae5d25.29cda","name":"3","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":660,"y":430,"wires":[]}]

[zenofmud]

Andrew, in the flow you provide the moment output is YYYY-DD-MM HH:mm:ss

[Trying_to_learn]

Yeah, I know.

I shall have to admit I may have goofed. Kind of.

But indulge my stupidity, because things are still as confusing as ever for me.

You said the output is YYYY-DD-MM which would imply that I am getting an incorrect output.

Here's the rub!

To try and work out the problem I again simplified the flow to:

Note the nice numbering: 1 and 2.

1 is wrong. 2 is right.

But it isn't all it seems.

Look at the screen shots:

Conclusion:

Originally I uploaded the code with the date formatted as YYYY-DD-MM and after local looking I saw a problem. ie: 2020-14-01 for example.

I changed the format to YYYY-MM-DD and thought nothing more of it.

Now when I am doing house keeping I am still seeing the problem.

There seems to be a problem with how the moment node is parsing the date.

When I have it set to do YYYY-DD-MM I am getting the desired output (eg) 2020-03-07 for today

When I have the node to do YYYY-MM-DD I get 2020-07-03

Or am I again missing something?

[Trying_to_learn]

Here is the flow:

[{"id":"981247e6.8d8b","type":"inject","z":"a941e919.4a7d88","name":"","topic":"","payload":"foo","payloadType":"str","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":400,"wires":[["35804bcb.cfa3b4"]]},{"id":"35804bcb.cfa3b4","type":"function","z":"a941e919.4a7d88","name":"Time Stamp","func":"var d = new Date().toLocaleString();\nmsg.payload = d;\nreturn msg;","outputs":1,"noerr":0,"x":300,"y":400,"wires":[["a14fc634.236a58","1e45ce85.75bc79"]]},{"id":"a14fc634.236a58","type":"moment","z":"a941e919.4a7d88","name":"1","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":440,"y":400,"wires":[["b475d6b2.e14ce"]]},{"id":"1e45ce85.75bc79","type":"moment","z":"a941e919.4a7d88","name":"2","topic":"","input":"payload","inputType":"msg","inTz":"Australia/Sydney","adjAmount":0,"adjType":"days","adjDir":"add","format":"YYYY-DD-MM HH:mm:ss","locale":"en_AU","output":"payload","outputType":"msg","outTz":"Australia/Sydney","x":440,"y":440,"wires":[["3e04c264.1fa166"]]},{"id":"b475d6b2.e14ce","type":"debug","z":"a941e919.4a7d88","name":"1","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":400,"wires":[]},{"id":"3e04c264.1fa166","type":"debug","z":"a941e919.4a7d88","name":"2","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","x":730,"y":440,"wires":[]}]

[Trying_to_learn]

(Sorry.....) To not want to trip you up on edited posts.

Another thing which is really confusing to me with the flow:

It is an inject node going to a function node which gets the current local time
That is split into two moment nodes and their outputs sent to their respective debug node/s.

Look at the times!

There is 20 seconds difference.
1 gets its message. 20 seconds later 2 gets its.

That is a (or should be) a worry.

[jtmoderate876]

Your flow works as expect for me here in the USA so I suspect the issue has something to do with how your country generally represents time combined with this:

var d = new Date().toLocaleString();

Try removing the function node:

[Trying_to_learn]

@jtmoderate876

Try removing the function node:

Thanks.

Alas, if only it was that easy.

The idea is that I am wanting to generate a time stamp and the input is not guaranteed to be a timestamped message.

The node gets an input and generates an output (3 actually) for use as needed:
For logging
as {msg.time}
For use as a file name.

Indulge me the problem with the reversed MM-DD and if you are seeing that.
(That MM-DD gives mm-dd output, and DD-MM gives mm-dd output)

For clarity, check the picture:
The "raw" message being sent to the moment node,
The output of the MM-DD node - note the date is date-month
The output of the DD-MM node - note the date is month-date

And how long it took.

[jtmoderate876]

From the info tab for the moment node:

String input warnings

Note that parsing date/time strings is a hard problem. moment.parseFormat helps but it isn't magic. We assume that ambiguous input dates such as 3/5/05 are in EU/UK format dd/mm/yy unless either the input timezone is in America or the locale is set to en_US .

[Trying_to_learn]

So where do I check if it is set to en_US or EU/UK?

The output from the function node is EU/UK format (date month) and it is asked/told to get local time
new Date().toLocaleString();

So to my understanding that is set correctly for here.

And the moment local is set to en_AU

[Trying_to_learn]

That didn't seem to help.

e@me-desktop:~$ sudo dpkg-reconfigure tzdata
[sudo] password for me: 

Current default time zone: 'Australia/Sydney'
Local time is now:      Sat Mar  7 09:56:20 AEDT 2020.
Universal Time is now:  Fri Mar  6 22:56:20 UTC 2020.

me@me-desktop:~$ 

[jtmoderate876]

the output of your function node:

is in the format of m/d/yyyy not EU/UK format and their notes state:

We assume that ambiguous input dates such as 3/5/05 are in EU/UK format dd/mm/yy unless either the input timezone is in America or the locale is set to *en_US .

[Trying_to_learn]

Yeah. Fair enough for that.

For me, I like dd mm yyyyy.
But for time lines I prefer yy mm dd

The javascript command gives 3/7/2020. That is what is given to the node to derive the date.

So I'm guessing it is a node problem.

Am posting information to the person now.

[jtmoderate876]

You could just move to the United States to get it to work .

[zenofmud]

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?

[Trying_to_learn]

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

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

Where abouts are you? (Just asking)

[Trying_to_learn]

Because I didn't know I could do that.

I'll look into that now.

Thanks.

[jtmoderate876]

@Trying_to_learn

Where abouts are you?

Suburbs of Chicago.

[Trying_to_learn]

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.

[Trying_to_learn]

(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.

[TotallyInformation]

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

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.