Hello all,
I am developing a custom app and I’m having some issues with date handling. I have been trying to write custom IML functions for parsing dates, but so far I haven’t been successful, and I suspect part of the reason is an inconsistency on how dates are fed to my custom function by Make. Specifically, this seems to be a problem for fields with type date
and { time: false }
- i.e., pure date fields, as opposed to date & time.
I have a search endpoint where I can define an array of filters. Each filter consists of three items: the field we want to filter by, the operation (equal, greater/lower than, etc.), and the value. The definition for the list of filters looks like this:
{
"name": "filters",
"type": "array",
"spec": [
{
"name": "target",
"label": "Field",
"type": "select",
"options": "rpc://getFields?includeSid=1&filterableOnly=1",
"required": true,
// Expect two nested fields: "operation" (equal, lower than, etc.) and "value"
"nested": "rpc://getFieldFilteringOptions?fieldApiName={{target}}"
}]
}
Then, when I want to make the call to the server, I set it up like this:
{
"body": {
"filters": {{parseAllDates(parameters.filters)}},
// ... omitted other parameters
}
}
This works as expected. If I try setting up a filter such that the search returns only records where mydate
is before today, it can look like this: [{ "target": "mydate", "value": "2024.02.20", "operation": "lt" }]
. The important bit here is that the date field is actually not parsed - it’s just a string with the date in my locale, and I should be able to use parseDate
to format it into a nice ISO string that the backend can handle.
However, this behavior is not what I’m getting in other cases. When I am going to create or edit records, the fields are also fetched via an RPC call, but in this case, they are all directly at the root level (i.e., not within an array or any sort of collection - so you’d access field x
by doing parameters.x
). This is what the parameters look like:
{
"name": "objectSid",
"label": "Object",
"type": "select",
"options": "rpc://getObjects",
"required": true,
"nested": "rpc://getFields?editableOnly=1"
}
Then the values are sent to the server like this:
"body": {
"{{...}}": "{{parseAllDates(parameters)}}"
}
The odd behavior is that in that case, every time that I have a date parameter, what I’m receiving in parseAllDates
is not a string, but a JavaScript Date. If, for instance, I select today’s date in the calendar widget when setting up the scenario, the field displays “20.02.2024” (with my locale - would be “2024-02-20” in ISO), but when I trigger the scenario, what parseAllDates
receives for this field is a JS Date object set to 2024-02-19 23:00 UTC. Notice that in doing this, the date has already changed - and the value that gets sent to the server is incorrect. Furthermore, at this point it seems like I cannot use parseDate
anymore, since this is a function that expects to receive a string rather than a Date.
I believe what is happening there is that in this case, Make is proactively parsing the date as though it was 20.04.2024 00:00 UTC+1 (my local timezone) and moving it to UTC, so that gets shifted to 19.04.2024 23:00 UTC. If that is the case, that seems like an odd thing to do - because conceptually, I’d expect that timezones wouldn’t be applied to “pure” dates without time.
Ultimately the issue is that in this case, by the time the value hits my function, it is not clear which is the date that was introduced by the user and that should be sent to the server. For instance, if my function were to receive a date pointing at today at 12:00 PM, that could mean that the user chose today and they are in a UTC-12 timezone, or they chose tomorrow and they are in UTC+12.
Passing dates in two different ways depending on whether the field is a root field or it lives within an array feels like a bug. However, if this behavior is going to be maintained, could you suggest any workarounds? For instance, is it possible to access a user’s timezone, or UTC offset, from within a IML function? That would allow me to work around this behavior.