When running the workflow, Edit Fields node outputs NULL for modifyTime (expression: {{ $json.modifyTime.substring(0, 10) }} ). When manually running the node, output is correct - please see attached.
Please share your workflow to provide more context
@Massimiliano_Bellini sounds like one of the items coming in doesn’t have modifyTime set, so the substring blows up on undefined. manual runs use pinned data but full runs hit every item. guard it:
{{ ($json.modifyTime ?? '').substring(0, 10) }}
also check the node feeding in, prob returning items where that field is missing
@Massimiliano_Bellini , you can also add null check
{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}
Hi everyone, quick update: as a workaround, I added a Date & Time node to format the date - ensuring that the node’s other inputs are also included as its output. That works well.
I still have a question: did I make a mistake in my previous workflow, or is there a bug in the Edit Fields (Set) node version 3.4?
Good troubleshooting, @Massimiliano_Bellini! Glad the Date & Time node workaround got things moving.
To answer your question - this is more likely a data inconsistency than a bug in Edit Fields itself. Here’s what’s probably happening:
The FTP list node returns files from the FTP server, and some of those files may genuinely have no modifyTime value set on the server side (null or missing entirely). When you run the node manually via “Execute Step”, you’re probably only looking at the first item in the test output, which happens to have a valid modifyTime. But in a full workflow run, all 9 items get processed, and some of them don’t have that field - which is why you get NULL.
The expression {{ $json.modifyTime.substring(0, 10) }} throws a TypeError when modifyTime is null or undefined, and n8n silently returns null for that field in that case.
The proper fix is to guard against null, exactly as others suggested:
{{ ($json.modifyTime ?? '').substring(0, 10) }}
Or if you want to preserve the null for files without a modify time:
{{ $json.modifyTime ? $json.modifyTime.substring(0, 10) : null }}
Your Date & Time node approach also works well because it forces n8n to handle the datetime formatting in a dedicated step that can deal with the null case more gracefully.
If this clarifies things, feel free to mark one of the replies as a Solution so others with the same FTP + null field issue can find this thread!
Hi Jay, thanks for taking the time to look into my issue. I also thank the others who sent me their reviews and suggestions. Based on what you all have said, I’m led to believe that what I’m experiencing isn’t actually a bug. However… the FTP node returns a correctly set “modifyTime” value for each item/file. Please take a look at the new test I just ran — you can see that when you run the workflow, the formatted date is enclosed in " characters
Edit Fields node - issue (debug).pdf (258.5 KB)
@Massimiliano_Bellini Thanks for sharing the debug PDF! That quote wrapping behavior is actually quite telling.
When the formatted date shows up as "2025-01-01" (with literal quote characters), it usually means one of two things:
1. The value from the FTP node is a JSON string that already contains escaped quotes. For example, the raw value might be "2025-01-01" as a string rather than 2025-01-01. You can strip them with:
{{ $json.modifyTime.replace(/"/g, '') }}
2. The Date & Time node is outputting a quoted string because the input isn’t being parsed as a proper date object. Try setting the “Input” field to use “Auto-detect” or explicitly set the input format.
The quickest way to test which it is: in a Code node right after the FTP node, log typeof $input.first().json.modifyTime. If it returns string and the value includes quotes, you have case 1. Strip the quotes before passing to the Date & Time node.
You can also just do it inline in Edit Fields:
{{ $json.modifyTime?.replace(/"/g, '').substring(0, 10) }}
That handles both the quote stripping and the null guard in one go.
Hi Jay, many thanks for your feedback.
Based on that, I added another Edit Fields node immediately after the first one (see the attached PDF) and now I get the correct formattedDate even when I run the entire workflow. Good.
Instead, if I use the expression {{ $json.modifyTime.replace(/"/g, ‘’).substring(0, 10) }} in the first Edit Fields node, then I get NULL values in OUTPUT when I run the entire workflow.
Edit Fields node - issue (debug 2).pdf (192.0 KB)
The NULL output in the first Edit Fields node happens because the expression {{ $json.modifyTime.replace("/", "").substring(0, 10) }} runs .replace() on a value that may still be a raw timestamp object (not a string) at that point. The FTP node often returns modifyTime as a JavaScript Date object or a number, not a string, so .replace() fails silently and outputs null. Try converting first: {{ new Date($json.modifyTime).toISOString().substring(0, 10) }} - this forces it to a proper ISO string before slicing. If modifyTime is already a formatted string like “2026/05/14”, then {{ $json.modifyTime.replace(/\//g, "-") }} (with regex, not just “/”) would handle all slashes correctly.
