# Node-red-contrib-moment - breaking update - looking for input

**URL:** <https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380>\
**Category:** Developing Nodes\
**Created:** [23 September 2018 14:25 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380 "2018-09-23T14:25:32Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [23 September 2018 14:25 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/1 "2018-09-23T14:25:32Z")

</div>

Hi all. I'm looking for input about a potential change to my [node-red-contrib-moment](https://github.com/TotallyInformation/node-red-contrib-moment/issues/14) node.

Currently, there is a slight issue when you supply data that isn't a date/time. According to the build-in warning, you should get an empty string as output. However, the documentation says that the current date/time will be used as input instead.

Whilst the documentation version is likely more useful to people, I'm concerned that a few people might be relying on the output being empty text. _If you are using this node, can you please let me know which you think would be best?_

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [23 September 2018 23:01 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/2 "2018-09-23T23:01:26Z")

</div>

@TotallyInformation, has this issue been closed by the release of v3.0.0? (I'm not seeing it yet on GitHub.) If so, how have you resolved it?

BTW, many thanks (again) for this enormously useful node.

---

<div class="post-metadata">

**Author:** ![JayDickson](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/jaydickson/32/90592_2.png) [@JayDickson](https://discourse.nodered.org/u/JayDickson)\
**Post date:** [23 September 2018 23:50 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/3 "2018-09-23T23:50:13Z")

</div>

I personally would prefer an empty string. Most of the time when I've used your node (awesome btw) it's been to either translate or migrate time series data. A blank timestamp would be much easier to filter out as an error case than a valid but inaccurate timestamp.

---

<div class="post-metadata">

**Author:** ![craigcurtin](https://avatars.discourse-cdn.com/v4/letter/c/94ad74/32.png) [@craigcurtin](https://discourse.nodered.org/u/craigcurtin)\
**Post date:** [24 September 2018 01:53 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/4 "2018-09-24T01:53:57Z")

</div>

+1 for me also - i would prefer invalid input gives a blank/NULL output

Craig

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [24 September 2018 06:05 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/5 "2018-09-24T06:05:47Z")

</div>

> [@drmibell](#):
>
> @TotallyInformation, has this issue been closed by the release of v3.0.0? (I'm not seeing it yet on GitHub.) If so, how have you resolved it?
> 
> BTW, many thanks (again) for this enormously useful node.

No, v3 has fixed a bug with input that is `null` (that case was producing an odd date in the past for some reason) and has updated Moment.JS and other libraries to current versions. But I decided to leave the overall processing as-is for now, pending the outcome of this discussion.

It seems like the consensus is to leave things as-is so that's what I will do. Thanks for the feedback.

Invalid inputs - any input that exists but cannot be converted to a date/time - will result in an empty string as output along with a debug warning message. If the input doesn't exist at all (e.g. you pass a non-existent msg/global/flow property) results in the current date/time being used as input.

Although I forgot to update the docs, you can also use the following convenience strings as input: "today", "yesterday", "tomorrow".

It is a pleasure to give something back to the community. I still have plans to add a couple more nodes to the library for other types of processing such as more detailed date/time calculations and duration processing. I also need to update the main node to allow more inputs from the msg. Sadly I always seem to be out of time these days. But PR's always welcome if you want to have a crack at something 😄

---

<div class="post-metadata">

**Author:** ![shrickus](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/shrickus/32/517_2.png) [@shrickus](https://discourse.nodered.org/u/shrickus)\
**Post date:** [24 September 2018 12:15 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/6 "2018-09-24T12:15:16Z")

</div>

> [@JayDickson](#):
>
> A blank timestamp would be much easier to filter out as an error case than a valid but inaccurate timestamp.

Agreed -- in the case of invalid input, does the node issue a warning that could be caught?

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [24 September 2018 12:32 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/7 "2018-09-24T12:32:45Z")

</div>

> [@shrickus](#):
>
> in the case of invalid input, does the node issue a warning that could be caught?

Currently, it doesn't. It issues a `node.warn` message but this isn't picked up by the catch or status nodes.

However, since an invalid input results in an empty string on the output, you can catch it that way using a switch node.

---

<div class="post-metadata">

**Author:** ![drmibell](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/drmibell/32/8424_2.png) [@drmibell](https://discourse.nodered.org/u/drmibell)\
**Post date:** [25 September 2018 02:02 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/8 "2018-09-25T02:02:48Z")

</div>

> [@TotallyInformation](#):
>
> It seems like the consensus is to leave things as-is so that's what I will do.

That makes sense. @JayDickson describes an valuable use case that should be preserved. I often use `moment` to attach a time stamp to a message when it reaches a particular point in a flow. There are plenty of ways to do that without breaking existing code, which is why I haven't followed up on "fixing" the issue of invalid string inputs.

> [@TotallyInformation](#):
>
> v3 has fixed a bug with input that is `null` (that case was producing an odd date in the past for some reason)

I think I understand what was happening here. moment.js was accepting `null` as a valid date, and interpreting it as zero. The result was `1970-01-01T00:00:00.000Z` (or its local equivalent), which is time zero of the UNIX Epoch. Perhaps reasonable but not useful.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [25 September 2018 15:00 UTC](https://discourse.nodered.org/t/node-red-contrib-moment-breaking-update-looking-for-input/3380/9 "2018-09-25T15:00:18Z")

</div>

> [@drmibell](#):
>
> I think I understand what was happening here. moment.js was accepting `null` as a valid date, and interpreting it as zero. The result was `1970-01-01T00:00:00.000Z` (or its local equivalent), which is time zero of the UNIX Epoch. Perhaps reasonable but not useful.

Thanks for the feedback. I guessed that null was being treated as a zero. Didn't seem right to me so it is no more! 🙂

Obviously, if anyone has any further suggestions, please feel free to raise here or on GitHub.