-
I'd only have it going down as far as seconds to YYYY-MM-DDTHH:MM:SSZ
-
"long" ? or "long date" [as its a short name
] Or maybe "full" or "full date"?
Simon
1 Like
Just to say more on the || Block
As I discovered recently, we are "stuck" with the core blocks
I think that getting round a small issue (such as OR not accepting anything other than true/false/a variable arguments ) and making a special block that doesn't really do anything different that a core one but is just a bit easier to use, is not a good idea.
As you know, I wanted text substring block to have shadow number blocks to save me time and mouse-effort in having to drag 2 blocks from the Maths category everytime I used it
I've now just accepted this as a limitation of Blockly.
I am actually starting to think that maybe we shouldn't even have a date block and just carry on with using node-red-contrib-simpletime before Blockly node and just the extrta properties it supplies
And just keep coding up things that are really, really needed inside Blockly node to achieve needed outcomes
Simon
I tend to agree. It is tempting to keep adding everything including the kitchen sink. It may be good to pause a while to wait to see what the "real" issues are faced by users. It is always easier to add extra features later, rather than have to deprecate/change/break or remove them later.
2 Likes
I agree 100% that we don't need a kitchen-sink-block ( thanks for the lovely words Dave 
). For example the ioBroker project has a series of blocks like send-email, send-tweet ... Since we already have great Node-RED nodes to accomplish that, we should indeed not add such blocks.
However dropping things like Date/Time blocks is not what I originally had in mind with my blockly node. In my humble opinion a blockly workspace for an IOT application needs to be able at least to process sensor data. This means 'to me' that it needs blocks to support Date / Time / Timers. Therefore I wanted to have those 3 categories of blocks in version 1.1.0.
So I would appreciate if you guys could assist me in designing those blocks, to make sure they become user-friendly.
Bart
You write the code and we'll give you the feedback
BTW Can we change the font to Comic Sans MS..................
1 Like
The real question is probably whether you feel the need to handle date/time edge cases such as local timezones and DST. If you do, then you really must use a library because handing dates and times is VERY complex.
However, the good news is that there are far simpler libraries available than moment which, while massively comprehensive, is equally massive!
I would say, keep things simple. So any blockly date/time processing should also be kept simple since we can always do further processing using existing Node-RED nodes. Some poor fool wrote a node that uses moment (ah-hem) so that would be an option for anyone wanting to do more complex processing.
1 Like
That is true... I just want to be able to do some basic date/time processing, so users could at least read/write/analyse timestamps of sensor measurements. No fancy stuff I assume ...
P.S. I had a look at how ioBroker has implemented this. They have added a formatDate function in their sandbox API, so the code running in the sandbox can call the date/time related code outside the sandbox. Therefore they don't need a 'require' in their generated code, but we cannot do it that way: the function node API doesn't have such date related functions in the function API, so the generated code couldn't be run in the function node anyway...
For what it is worth, I generally encourage folk to stick with ISO formatted UTC date/times for all intermediate processing with conversion to local times only for display. This makes everything predictable and the ISO format is sortable even in string format.
So I'd probably say - don't include a date/time format option at all, if anything, stick to ISO. Let other nodes handle the complexity. Encourage users to stick with UTC dates and times.
2 Likes
As a break from dev stuff - i was reading in another thread about returning mulitple messages from a function node so I had a quick play and cam up with this demo.
it creates two objects and then creates a list with them and puts that two element list as a single element inside another list - and then returns that object onward 
In case anybody might be wondering if we have sleeping, the answer is very simple : Nope !
Have developed some date/time related blocks and the following two will be released in version 1.1.0:
- The 'timestamp' block generates a timestamp, similar to a new timestamp generated by an inject node.
- The 'get ... from timestamp ...' allows you to get a bunch of information from a timestamp:
They have already been tested by @cymplecy, which ensures us that those blocks even can survive a third world war with drones, transformers, nuclear rockets and other destructive war material...
In the next test case from Simon, we inject a timestamp in the blockly node:
And this will be the output:
We will start finishing the current developments, to be able to finish version 1.1.0. All other stuff will be postponed to version 1.2.0 ...
1 Like
@TotallyInformation: all is in UTC time...
1 Like
Version 1.1.0 has been published.
We will continue our discussion in the new thread, and stop posting here!
3 Likes
