But if passed date is after the 13th of the month, it’s correctly interpreted.
Even help page about formatDate shows the bug:
formatDate(now;MM/DD/YYYY HH:mm) results in 19/03/2019 15:30
How Make is still in business with such major bug is beyond me.
After searching for help, I’ve tried parsingDate in various ways:
parsing original datetime variable results in errors:
{{formatDate(parseDate(6.datetime; “YYYY-MM-DD HH:MM”); “DD/MM/YYYY HH:mm”)}}
parsing date and adding time to it:
{{formatDate(parseDate(6.date; “DD MMMM YYYY”); “DD/MM/YYYY”)}} {{space}}{{formatDate(6.time; “HH:MM”)}}
countless hours lost in lots of combination to not avail
Is it possible to sync an acuity appointment to a notion calendar ?
If so, how are the one doing it managing that date formating issue ?
I think one of the issues is that Notion expects a date/time variable rather than a string as input into the Notion function. formatDate() outputs a string in the masked format.
Why are you needing to format it at all? Have you tried passing the date time from Acuity variable directly into Notion without any formatting? The date time should be standard between the 2 systems. Where are you reading that Notion expects that variable in the specific format?
I first tried to simply pass the date object straight and not a string but it didnt work and it seems perfectly fine once it receives a correctly formatted date string. It’s a matter of format.
Instructions are written right in the make window, just like in the screenshot provided. Also, it works as soon as it receives a correctly formatted string, so I guess it’s why I came to that conclusion.
Also I tried providing a date object using parsingDate but could not solve all errors at runtime.
And the function formatDate est clearly bugged so it’s not just a typo in the help. It’s a real output I believe.
This is what I expect since my org is -0500. Note that the day and month are properly formatted. I didn’t even use parseDate on the string as since this is the standard format of a date formatDate just took this string as a date and properly formatted it.
This also seems to work although I think it is is unnecessary to parseDate()
this isn’t going to work - parseDate() expects the mask to be the same as the first argument to create a date object from a string. You have a mismatch here.
{{parseDate(“2024-01-06T09:00:00+0100”)}}
this on the other hand (leaving off the mask entirely) will parse the date into a Zulu date in the output
“date1”: “06/01/2024 03:00”
am quite surprised you couldn’t reproduce the bug.
As my screenshots show, I do not get same results.
How did you get those experiments results exactly ? I mean where could one test a function ? have you hardcoded this in a module ?
{{formatDate(parseDate(“2024-01-06T09:00:00+0100”); “DD/MM/YYYY HH:mm”)}}
As for parseDate function, am also surprised one could use it without any parameters after the date itself. Help page did not specify formatting is optional.
{{formatDate(now; "DD/MM/YYYY HH:mm")}}
returns “dateformat”: “22/12/2023 13:02”
The now date test thought is expected to not show the bug since day of the month is after the 12th. Only difference I see is the use of mm instead of MM. You gave explaination about the difference in use of HH vs hh but not about MM vs mm.
whatever I try give the same result again and again:
{{formatDate(6.datetime; “DD/MM/YYYY HH:mm”)}} outputs june 1st instead of january 6ht{{formatDate(parseDate(6.datetime); “DD/MM/YYYY HH:mm”)}} outputs june 1st instead of january 6ht
{{formatDate(6.datetime; “DD/MM/YYYY HH:MM”)}} outputs june 1st instead of january 6ht.
{{formatDate(parseDate(6.datetime); “DD/MM/YYYY HH:MM”)}} outputs june 1st instead of january 6ht
{{formatDate(parseDate(“2024-01-06T09:00:00+0100”); “DD/MM/YYYY HH:mm”)}} outputs june 1st instead of january 6ht
{{formatDate(“2024-01-06T09:00:00+0100”; “DD/MM/YYYY HH:mm”)}} outputs june 1st instead of january 6ht
The mm for minutes is not the same as MM for month. If you use it in the wrong place you’ll grab the wrong component into your output. They are NOT interchangable as they represent different parts of the date.
I am fairly sure there is no bug before the 12th of the month or after. It would have been found and fixed long ago so something else is going on.
I just realized something – if the users’s locale options are consistent with the source data or is Make just showing you values in your locale format?
Notion module seems indeed to require a date type variable and I kept trying to format it as a string. Automatic type coercion might be the culprit reversing month and day whenever it can (ie day is before the 12th and could be confused with month number).
Just passing the datetime variable provided by acuity module was my very first try though and it raised an error. Then trying to solve that error I tried formatting and digging myself in.
I believed now it raised an error because my UI and or browser had bugged.
While testing extensively I added another notion create database item and noticed this one had a field other create item modules had not (a notion relation field). When I first added those notion creation modules I did not know it was a bug. I just thought that having to add a update database item just to be able to access that field was poorly made but it made sense since I had to use 2 acuity module (one to watch trigger and one to get appointment data).
For some unknown reason those create item module had not that field available and have likely raised false error when I tried to just input the acuity datetime variable in the notion date field.
That is what I thought by looking at the UI for the output or input bundle in notion.
Glad you got it working. I tend to avoid any date time conversion unless I need to output to a text string somewhere. But these date time fields in the apis are almost always native date time fields.
