add more datetime support, type-independent log block , CRLF block

[stefan-hoehn]

1. Added multiple ZonedDateTime-Blocks based on ideas and implementations of deibich - see https://community.openhab.org/t/date-and-time/131329

• added oh_zdt_now
• added oh_zdt_create
• added many more date patterns that can be detected by the getZonedDateTime()-Method used by oh_zdt_fromText
• added more flexible oh_zdt_amend (flexible way of assembling various combinations of amending a ZDT via oh_zdt_temporal_unit) instead of three specific "copy of" of deibichs idea
• added oh_zdt_temporal_unit and oh_zdt_temporal_unit_field for oh_zdt_amend
• added oh_zdt_fromItem
• added oh_zdt_compare
• added oh_zdt_between
• added oh_get_zdt_part
• added oh_get_time_between
• supports using variables
• rearranged order of the blocks
• moved persistence specific date blocks to persistence section

Note: set item from deibichs implementation was not ported as this can be done with a normal "send command"
2) OH Blocks are expanded by default
3) Logging-Block allows any input type

Also-by: deibich
Signed-off-by: Stefan Höhn stefan.hoehn@nfon.com
Big thanks goes to @tweini within the blockly community.

[relativeci]

Job #409: Bundle Size — 10.74MB (+0.28%).

ca75306 vs 56d9243

Changed metrics (2/10)

Metric	Current	Baseline
Initial JS	1.67MB(~-0.01%)	1.67MB
Cache Invalidation	16.7%	60.47%

Changed assets by type (1/7)

	Current	Baseline
JS	8.68MB (+0.34%)	8.65MB

---

View Job #409 report on app.relative-ci.com

[ghys]

Thank you Stefan, a few remarks as I was testing this PR:

I'm not sure "ZDT" as a technical acronym would be understood by novices; there ought to be a more user-friendlier identifier for them

Not sure what this does, I have some idea with my technical background but regular users will IMO surely be confused.

[stefan-hoehn]

Hi Yannick,

Thank you Stefan, a few remarks as I was testing this PR:

I'm not sure "ZDT" as a technical acronym would be understood by novices; there ought to be a more user-friendlier identifier for them

I agree on the ZDT-acronym. The reason I used it that I took over from deibich's implementation which you liked pretty well. How about replacing it with datetime or even zonedDatetime.

Not sure what this does, I have some idea with my technical background but regular users will IMO surely be confused.

I actually showed this several people including @Confectrician in a live demo before completely implementing it. As soon as you we have merged this code I will document it and you will see it is straight forward and easy to use.

How to use it

• add any ZDT
• open the cog and add as many temporal unit in the mutator
• add one of the two temporal unit blocks (either the flat field or the input, which allows more flexibility, to your block)
• change the type of the temporal unit block with the -> of the block.

copyOfDemo.mov

Once you get the hang of it it is really straight forward and pretty easy. I intend to add an animated gif (like above) to the docu showing how to use it

[Confectrician]

Hi all,

Jumping in here through the mention.
Stefan and I had a video call during the implementation of this and he showed me his thoughts behind it.

Yes. There might be kind of a learning curve.

But when you are a bit familiar with it, you can use one single block in a highly flexible way and just have to combine the same parts in a different way.

[ghys]

I agree this is great stuff but I'm really still unconvinced about "ZDT" - it really doesn't mean anything for the casual user (and you can't expect casual users to go check out the openHAB docs to figure that out, I believe especially in Blockly things have to be approachable and naturally tailored for non-technical users) - however if it was spelled out completely as "ZonedDateTime" or even "zoned date time" then they could at least google it and learn about what they're dealing with. Just my opinion ;)

Edit: turns out searching for "zoned date time" gives at least relevant results on:

• Google: https://www.google.com/search?q=zoned+date+time
• DuckDuckGo: https://duckduckgo.com/?q=zoned+date+time

So this would have my preference.

[Confectrician]

Hm Stefan agreed in renaming already and is probably only waiting for feedback on his suggestions.

I agree on the ZDT-acronym. The reason I used it that I took over from deibich's implementation which you liked pretty well. How about replacing it with datetime or even zonedDatetime.

My 2 Cents:
I would go for DateTime to keep it simple and probably make some note in the docs/help that it technically is a zoned datetime.

[stefan-hoehn]

I agree this is great stuff but I'm really still unconvinced about "ZDT" - it really doesn't mean anything for the casual user (and you can't expect casual users to go check out the openHAB docs to figure that out, I believe especially in Blockly things have to be approachable and naturally tailored for non-technical users) - however if it was spelled out completely as "ZonedDateTime" or even "zoned date time" then they could at least google it and learn about what they're dealing with. Just my opinion ;)

Edit: turns out searching for "zoned date time" gives at least relevant results on:

• Google: https://www.google.com/search?q=zoned+date+time
• DuckDuckGo: https://duckduckgo.com/?q=zoned+date+time

So this would have my preference.

As mentioned above am fine with both date time and zoned date time. As date time is shorter I will change it that asap.

[ghys]

I agree on the ZDT-acronym. The reason I used it that I took over from deibich's implementation which you liked pretty well. How about replacing it with datetime or even zonedDatetime.

Sorry I completely missed that part. I just was focused on the "add temporal units" block video ;)
The difference - I think - between adding a block library that has "ZDT" blocks and having "ZDT" blocks in the built-in library is that in the former case you choose to add that block library so you have a chance to read what it does and what "ZDT" means. In the latter case you don't, you're just presented with "ZDT" and have to figure it out.

[stefan-hoehn]

:-)
Very well so, I will change it to show "datetime" in the blocks then. I like that also much more than ZDT.

This is how it looks finally after changing it to datetime (now pushing it)

[stefan-hoehn]

@ghys As the next milestone is around the corner would it be possible for you (or anyone else) to merge my Pull Request?

[ghys]

I'm currently abroad without a laptop, I'll finish the review over the weekend after I return!

[stefan-hoehn]

Thanks for being so rigid on the review (I looked at it) - I appreciate it.

One question regarding

:expanded="$f7.device.desktop"

How does that work?

...strange that the JAVA-Build fails.
(btw, did you see my forum mail info I sent you regarding the echart-version problem?)

[ghys]

I restored the original package.json / package-lock.json as I haven't been able to immediately fix the peer dependencies issues. I'll address that another time in another PR.

As answered on the forum please refrain from updating unrelated dependencies and committing/submitting the result as a PR (or more generally anything unrelated to the PR itself), it avoids some headaches! :)

[ghys]

I'm leaving some notes on the implementation of those big utility functions, and other remarks, but I won't ask you to address those at least not in this PR.

[ghys]

I didn't quite understand why the % 1000 for micro & nano. For nano I seem to always get 0.
In fact I wonder if anything below a millisecond is really necessary, who would ever need them?

[stefan-hoehn]

First of all I didn't want to deviate from deibich's implementation as he had implemented nanos (and yes, you could of course question whether nanos are really necessary). I then went further because millis and nanos where there but micros was missing, so for consistency reasons I have added them.

Regarding your note I checked the behaviour with

which results into

2022-05-30T11:34:26.855407+02:00[Europe/Berlin]
2022-05-30T11:34:26.855407123+02:00[Europe/Berlin]
123

So, you are right that now does not include Nanos itself, so we could have omitted them. Sure, you can set and add and subtract them but the question really is how much sense that makes.

Would you vote for removing nanos everywhere? I would then remove them with another PR.

[ghys]

This seems to be an implementation of ZonedDateTime.of so why not use it directly?

Since these functions are injected when you inject date support whether you need to call them of not, and are quite long, they tend to clutter users' scripts very quickly, so the fewer, the better. Besides we should IMHO use the best possible reference implementation when injecting things into user scripts.

[stefan-hoehn]

Good hint.

so why not use it directly?

for two reasons:

1. I took that over from deibichs implementation directly
2. I wasn't aware of that zdt.of

I will see if I can optimize that eventually.

[ghys]

Similarly, instead of injecting this huge utility function, since those compareOp/precision/compDate are fields, you could generate the code dynamically, using temporary variables to store copies of zdt1 & zdt2 with the "precision" and "compDate" logic, then generate the code that you need dynamically.
In other words this big switchs/cases utility function should have been implemented in the code generation for the blocks instead.

[stefan-hoehn]

I will add that to my todo list and see what I can do here.