Is Date Comparison Possible with a Filter or Requires a Code Step for ISO 8601 Text Format?

This topic was automatically generated from Slack. You can find the original thread here.

I want to do date comparisons with a Filter, is that possible or do I need to write a code step instead of a Filter?

The dates provided by the source webhook are in text format (ISO 8601).

Nevermind, looks like I can

can you show me how to do date comparisons with a Node.js code step when the trigger’s event body contains a datetime string under the timestamp property?

Sure! You can use a Node.js code step to compare dates when the trigger’s event body contains a datetime string under the timestamp property. Here’s an example of how to do this: export default defineComponent({ async run({ steps }) { // Get the timestamp from the trigger's event body const timestamp = steps.trigger.event.timestamp; // Convert the timestamp string to a Date object const date1 = new Date(timestamp); // Create another Date object for comparison const date2 = new Date(); // This will create a Date object with the current date and time // Compare the two dates if (date1 > date2) { console.log("Date 1 is greater than Date 2"); } else if (date1 < date2) { console.log("Date 1 is less than Date 2"); } else { console.log("Date 1 is equal to Date 2"); } }, }); This code will compare the timestamp from the trigger’s event body with the current date and time, and log the result of the comparison. You can modify the comparison logic and the second date as needed for your use case.

Nah, I did this instead - unless there’s some reason this won’t work?

Sure! That way works too. Just a matter of preference

What happens if the steps.trigger.event.created_at or steps.trigger.event.closed_at isn’t defined or not in the correct format? Does the workflow error, or?

Yes, you should use optional chaining to handle possible missing values.

One of the nice parts of using code is for validation like this. It might be easier to validate/transform or define fallbacks in code first. Then consume in pre-built steps downstream.

can you show me how to define a fallback value with a nested object property that’s accessed with optional chaining?

Then can you show me how to use that in a double bracket JS evaluation in a prop for a pre-built action?

Yes, you should use optional chaining to handle possible missing values.
We actually just shipped optional chaining by default! (transparently)

Sure! First, let’s define a fallback value with a nested object property that’s accessed with optional chaining. Here’s an example: const event = { data: { timestamp: "2022-01-01T00:00:00Z", }, }; const fallbackTimestamp = "2000-01-01T00:00:00Z"; const timestamp = event?.data?.timestamp || fallbackTimestamp; In this example, if event.data.timestamp is not defined or not in the correct format, the timestamp variable will be assigned the value of fallbackTimestamp. Now, let’s use this value in a double bracket JS evaluation in a prop for a pre-built action. Assuming you have a pre-built action that accepts a timestamp prop, you can use the double bracket notation like this: {{ timestamp }} In the Pipedream UI, when configuring the pre-built action, you would set the timestamp prop to {{ timestamp }}, which will pass the value of the timestamp variable from the code step to the pre-built action.

Eh I could have prompted that better. Not your fault Mario.