Gathering detailed insights and metrics for node-red-contrib-moment
Gathering detailed insights and metrics for node-red-contrib-moment
Gathering detailed insights and metrics for node-red-contrib-moment
Gathering detailed insights and metrics for node-red-contrib-moment
npm install node-red-contrib-moment
v4.0.0 - Dependency update, output settings, bug fix
Published on 04 Oct 2020
Humanizer contribution merged
Published on 13 Apr 2017
Major rewrite with tz/locale awareness and more
Published on 26 Jun 2016
Bug fixes & contributor acknowledgement
Published on 12 Jun 2016
Added Locale support (thanks to @Jacques44)
Published on 30 Mar 2016
First stable release
Published on 10 Mar 2015
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
34 Stars
113 Commits
16 Forks
7 Watching
5 Branches
6 Contributors
Updated on 26 Aug 2024
Minified
Minified + Gzipped
JavaScript (56%)
HTML (44%)
Cumulative downloads
Total Downloads
Last day
-37.8%
475
Compared to previous day
Last week
32.1%
3,453
Compared to previous week
Last month
35.7%
11,793
Compared to previous month
Last year
-8.8%
138,603
Compared to previous year
4
1
Please note that this node is unlikely to recieve further enhancements now that moment.js is built into JSONata and so is available from change, function and other nodes.
Node-RED node moment produces a nicely formatted Date/Time string using the Moment.JS library. The node is fully time zone/DST/locale aware.
Node humanizer converts time durations (time spans) into textual descriptions (e.g. 2 minutes).
Both nodes are locale aware regarding the language of the output strings.
Fig. 1: Node appearance
Based on thoughts from a conversation in the Node-RED Google Group. Updated with timezone/locale capabilities after Jaques44's initial work. Updated with +/- adjustments after another conversion in the Google Group.
Basic installation:
~/.node-red
npm install node-red-contrib-moment
To get the latest development version, install with:
npm install TotallyInformation/node-red-contrib-moment
The easiest usage of the node is feeding it with an timestamp inject:
Fig. 2: Basic usage node moment
Please see the CHANGELOG document.
The node generally expects an input from the incoming msg. By default, this is msg.payload. If it is a recognisable date/time, it will apply a format and output the resulting string or object accordingly.
Input and output time zones are settable as is the output locale. All of which default to the host systems tz/locale.
This allows the node to be used to translate from one time zone to another. It also will take into account daylight savings time (DST).
You can also apply an adjustment to the date/time by adding or subtracting an amount.
Fig. 3: Properties of node moment
These two configuration properties define the msg
properties in which the input and output data are read from resp. written to. Default is msg.payload
.
This property defines the timezone of the time fed via the input msg
. Internally the input time is converted into UTC for further processing.
The format of Input Timezone is in the format region/location, e.g. Europe/London. See also timezone lists e.g. built in to moment-timezone or given in wikipedia.
Note: Spellings are not validated, if it doesn't seem to work, check the validity of region/location with these timezone lists.
The following behaviour is valid:
dpkg-reconfigure tzdata
on Linux), the input timestamp is related to this local timezone.If left blank in settings, this field may be set from the incoming msg.inTz
property.
This property defines the timezone of the time emitted via the output msg
.
The format of Output Timezone is described above (see Input Timezone).
The following behaviour is valid:
If Output Format is left blank, the output format is in 'Zulu' format, independent of the contents of the additional properties Output Timezone and Locale.
Zulu format see: https://momentjs.com/docs/#/displaying/as-iso-string/
(Example: 2013-02-04T22:44:30.652Z)
If left blank in settings, this field may be set from the incoming msg.outTz
property.
Using this property, the time can be adjusted by a manually given value. Adjustments can be positive or negative and can be given in milliseconds, seconds, minutes, hours, days, weeks, months, quarters, years.
These two properties in combination define the output format emitted in the output msg
.
The Output Format property defines the format and is described in the moment.js displaying format section.
It may be any format string defined by moment.js. The formatting additions from moment-timezone are also allowed. In addition, further (not case sensitive, alternatives in brackets) format strings are also allowed.
Note that with the exception of ISO8601, other formats are in the specified timezone & DST. If not specified, the output timezone/DST is the same as the input.
Use an output timezone of UTC to force output to that.
The format string defined by moment.js basically has two options:
Manual given format string: This is a string where the time/date parts are represented by characters. Also text parts are allowed. Examples:
Predefined localized string: This is a string which defines a localized format. Examples:
For more options see https://momentjs.com/docs/#/displaying/format/.
In this case the output is in ISO 8602 format, e.g. "2015-01-28T16:24:48.123Z".
Note that ISO8601 formatted output is ALWAYS in UTC ('Z', Zulu time) not local, no matter what output timezone you may specify.
See also moment().toISOString()
.
This is a Javascript Date object in the form {years:nnnn, months:n, date:n, hours:n, minutes:n, seconds:n, milliseconds:n}
.
It may be used for manual (fixed) data/time values.
WARNING: moment.js has a bizarre object format where the month is zero-based (0-11) instead of 1-based (1-12) like all the other elements are. I don't currently know why, I've raised an upstream issue but this appears to be a deliberate decision for some strange reason.
See also moment().toObject()
.
This is a human readable output, e.g. 30 minutes ago or in a month (only rough time spans are given in this output format type, see also the humanizer example below). The time span is derived from the actual time and the time fed into the node.
See also moment().fromNow()
.
This is a human readable alternative, e.g. Last Monday or Tomorrow 2:30pm. Note that dates beyond a week from now are output as yyyy-mm-dd.
See also moment().calendar()
.
This output format type is actually not working (see issue #37).
In case of a textual output string contents the Locale property defines the language of the textual parts (e.g. "October" vs. "Oktober" vs. "ottobre" vs. "lokakuuta").
If the output is shown in the wrong format, such as dates in US mm/dd/yy format, change the output locale. For example, using en_gb will force short dates to output in dd/mm/yy format. The default is en which moment assumes means the USA :-(
See also Locale Helper (Note: Not every locale given there is supported).
Using this property you can add an additional topic to the output msg.topic
.
A resulting msg
may be (value "myTopicString"):
1{"_msgid":"b16b00b5.bada55","payload":"2020-09-20T12:47:55.143Z","topic":"myTopicString"}
Input values in the object Input from can be of the following types:
timestamp: The current date/time is used as input.
msg, global or flow and the given property is empty or does not exist: The current date/time is used as input.
JSON date time object: This data time object may contain the following elements: years, months, days, hours, minutes, seconds, milliseconds.
Example: {"years":2020,"months":1,"date":11,"hours":5,"minutes":6}
.
If elements are not given (e.g. years and months are missing in the object) the actual time values are used instead.
a property containing a string that is a recognizable date/time: The value will be interpreted and processed.
Example: 2020-02-11T05:06
a property containing a numeric value: The value will be assumed to be a UNIX time value (ms since 1970-01-01). Remark: This is the format which the node Inject emits at option timestamp.
a property containing a string that is not a recognisable date/time (including null
): Then no conversion takes place, the output will be an empty string plus a debug warning.
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.
If the output property is not msg.payload
the input msg.payload
is retained in the output.
The date/time output is a formatted string if the configuration property Output Format is anything other than date resp. jsDate or object in which case the output is a Javascript date object or an object as described below respectively.
Output string formatting is controlled by the Locale and the Output Format setting. Note that the output Timezone is ignored for ISO8601 output (the default), such output is always in UTC. For other formats, the output will be in the specified timezone which defaults to your host timezone.
Specifying different input and output timezones allows you to translated between them.
The output msg
will pass through the input msg.topic
unless it is overridden by the Topic configuration property. If the Output to field is changed from the default msg.payload
, the input msg.payload
will also be passed through.
This node converts an input time span to a humanized text string to the output msg.payload.humanized
. The language of the output string is derived from the locale of the system, i.e. it is not changeable (like the Locale property of the moment node).
See also moment.duration().humanize().
(Contributed by Laro88)
Fig. 4: Properties of node humanizer
This property defines the input msg.payload
property which shall be used for the conversion. If left blank, msg.payload
is used.
The input is a number which defines a time span in seconds.
The output is a string object in msg.payload.humanized
.
The time spans are evaluated in intervals, see humanizer example for details.
Remark: Example flows are present in the examples subdirectory. In Node-RED they can be imported via the import function and then selecting Examples in the vertical tab menue.
All example flows can also be found in the examples folder of this package.
The basic usage is shown in Fig. 2. The following examples shall give an overview how to use the rich configuration properties.
A sample flow is:
output-timezone-format-adjustment flow
Fig. 5: Example flow showing the usage of Output Timezone, Output Format and Adjustment
A sample flow is:
input-timezone flow
Fig. 6: Example flow showing the usage of Input Timezone
A sample flow is:
output-format-locale flow
Fig. 7: Example flow showing the usage of Output Format and Locale
A sample flow is:
humanizer flow
Fig. 8: Example flow showing the usage of the humanizer node
Summary of things I'd like to do with the moment node (not necessarily immediately):
Add some additional nodes for doing date/time calculations - partly complete, can do simple add/subtract from main node
Add additional node for doing duration calculations
Add a combo box to the Format field with common formats pre-populated
Improve the error messages when Moment.JS fails to interpret the input (say why)
Allow more input date/time formats - turns out Moment.JS doesn't really help here. At present, I see too many input failures from US/UK date formats, etc. It would be great if I could parse "human" inputs like "tomorrow" and "2 minutes from now". We can output them now but not input them. As of v1.0.5, a localisation parameter is supported.
Partly complete: Added the parseFormat plugin. That failed, see code for details. Now complete.
This code is Open Source under an Apache 2 License. Please see the apache2-license.txt file for details.
You may not use this code except in compliance with the License. You may obtain an original copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. Please see the License for the specific language governing permissions and limitations under the License.
Julian Knight (Totally Information), https://github.com/totallyinformation
Many thanks for the contributions.
Please report any issues or suggestions via the Github Issues list for this repository.
For more information, feedback, or community support see the Node-RED Google groups forum at https://groups.google.com/forum/#!forum/node-red
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
1 existing vulnerabilities detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 1/22 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
security policy file not detected
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More