0.200.1 release - hosted install - Invalid weekData time manipulation issue, Locale Issue?

Questions
1

I’ve been using 0.198.2 quite happily and doing simple date time manipulation using the following syntax:

item.checkfromtime = $now.minus({minutes:$node["SetConfig"].json["checkTimeLastMinutes"]});

Which would return


"checkfromtime":"2022-10-31T18:34:26.238+00:00"

But I just rolled it on to using 0.200.1 and now that SAME function appears to have been broken, with invalid weekData ?

My TZ=Europe/London

It now returns a message about Invalid weekData:

"checkfromtime":{
  "ts": 1667239642354,
  "_zone": {
    "zoneName": "Europe/London",
    "valid": true
  },
  "loc": {
    "locale": "en-US",
    "numberingSystem": null,
    "outputCalendar": null,
    "intl": "en-US",
    "weekdaysCache": {
      "format": {},
      "standalone": {}
    },
    "monthsCache": {
      "format": {},
      "standalone": {}
    },
    "meridiemCache": null,
    "eraCache": {},
    "specifiedLocale": null,
    "fastNumbersCached": null
  },
  "invalid": null,
  "weekData": null,
  "c": {
    "year": 2022,
    "month": 10,
    "day": 31,
    "hour": 18,
    "minute": 7,
    "second": 22,
    "millisecond": 354
  },
  "o": 0,
  "isLuxonDateTime": true
}

I’ve rolled back to 0.198.2 and the configuration is back working. Do I need to sort out the LOCALE ? I noticed that in the message it mentions en-US formatting.

2

Also noticed this, thought it might’ve been my own changes. I had to add a .toString() to my date object.

Pretty sure I saw a PR about stringifying data between nodes which would explain the opposite of this happening :thinking:

3

Ok - I’ve got a few workflows that I’d need to go and update :frowning: … oh now where is the ‘search’ feature :slight_smile: … for the moment I’m exporting all the workflows in the container and then issue a

grep -H  \$now *.json  | awk -F : '{ print "head -5 "$1" | grep name" }' | ash

Unless there’s a better way of finding which flows might have some specific jscript in ?

4

That’s probably the best way at the moment, use the tools you know.

Still not sure this is intended, will look through the commits between versions tomorrow to see if I can pinpoint it.

5

I have just given this a quick go with the workflow below, It seems to be working but the item has extra quotes around it on return, Is that what you are seeing?

6

I have also seen that in another workflow, but in my original one I am getting back an object.

function:

function addBusinessDays(start, businessDays, inclusive=false) {
    end = start;
    if (inclusive && start.weekday > 0 && start.weekday < 6 ) {
        businessDays--;
    }
    while (businessDays > 0) {
        end = end.plus({days: 1});
        // If is weekday
        if (end.weekday > 0 && end.weekday < 6) {
            // console.log(`${businessDays}: ${end.weekdayShort} is business`)
            businessDays--;
        } else {
            // console.log(`${businessDays}: ${end.weekdayShort} is not counted`)
        }
    }
    return end.set({ hour: 23, minute: 59, second: 59, millisecond: 999 })
}

item.endDate = addBusinessDays(DateTime.fromISO($json["Due Date"]), 5, true)

return item;

Before the upgrade I’d get:
"endDate":"2022-10-21T23:59:59.999+11:00"

After the upgrade:

{
  "ts": 1762433999999,
  "_zone": {
    "zoneName": "Australia/Sydney",
    "valid": true
  },
  "loc": {
    "locale": "en-AU",
    "numberingSystem": null,
    "outputCalendar": null,
    "intl": "en-AU",
    "weekdaysCache": {
      "format": {},
      "standalone": {}
    },
    "monthsCache": {
      "format": {},
      "standalone": {}
    },
    "meridiemCache": null,
    "eraCache": {},
    "specifiedLocale": null,
    "fastNumbersCached": null
  },
  "invalid": null,
  "weekData": null,
  "c": {
    "year": 2025,
    "month": 11,
    "day": 6,
    "hour": 23,
    "minute": 59,
    "second": 59,
    "millisecond": 999
  },
  "o": 660,
  "isLuxonDateTime": true
}

Where I’m seeing additional " is with (like it’s being JSON stringified):
item.json.fromDate = $today.minus({ days: retention })

The solution for both is to append .toString()

7

OK so that businessDays function will return an object in the old Function Item node, but using the code node will return the string with inverted commas around.

8

That is interesting and makes it easier to see the issue, I wonder what we changed there.

9

To simplify, the base case is simply:

// code node
$input.item.json.endDate = DateTime.fromISO('2022-11-01');
return $input.item;

// function node
item.endDate = DateTime.fromISO('2022-11-01');
return item;
10

Yeah this is exactly it - If I leave the code in an old Function node it fails but put it into a new code node then it seems to be ok.

I’ve just run up two different containers (0.198.2 and 0.200.1) on the same host copy/paste the basic function nodes between them and the node past and future compatibility issue appears. e.g. still allows the old node style but breaks the functionality of the workflow.

11

Morning,

I have added this to an internal ticket we have n8n-5282, I am not sure if this was intentional and we just missed a breaking change notice or if we didn’t mean to do this. For now it will be a case of tweaking the script or using the older version until we know.

1 Like
12

I’ve just gotten around to loading up 0.201.0 on my test platform and the issue appears to have been resolved in that release.

The old function node with the time manipulation is back working.

2 Likes