Hi @knuggie,
This is a date transfer bug, which is related to the way Adalo works with dates. I’ve reproduced it in my test app - same effect.
I think the reason is the following.
To start with, Adalo internally stores DateTimes and Dates as number of days since 1/1/1970. For DateTime, Integer value represents the date, and decimal represent the “fraction of the day”.
E.g. 19196.25 is equal to 6AM, 23rd of July 2022 in GMT+0 time zone. Then, the actual time displayed for a user is adjusted using user’s timezone settings. For someone in New York (GMT-4) this date will be displayed as 2AM same day (though, of course, the value stored doesn’t change).
For Dates, only Integer value is stored in the database (e.g. 19196 for 23rd of July 2022).
I guess in your case the following happens. When you update the date property in the first collection, it is stored correctly (as 19196 for today).
But when you update the date property in the second collection with the date from the first one, here is what might happen:
- Adalo takes the date as “date” (e.g. 19196)
- then it adjusts it to your timezone (prepares it to display as 8PM 22nd of July)
- and when it stores it to the second collection, it does another conversion from Datetime to date (8PM 22nd of July → 22nd of July = 19195).
This bug will exist for the countries with timezones to the west of Greenwich.
What could be done here:
- store dates in datetime format (potential issues for the users from very different timezones)
- use numeric property to store the date’s value “in between”.
Hope this was useful.
Best,
Victor.