@sadalo Now I got your point (I hope 
)
The short answer is: The Adalo database is handling the time conversion including DST - and we have not way to influence it. There is no setting (like in Airtable!) to include or exclude timezone conversion).
And:
There is a timezone problem with this workaround to calculate with date and time.
That is what I know:
The values for Date/Time property are stored in the database including the timezone information calculate down to UTC.
That means if I store a date with 16:00PM in my timezone (UTC+4) it actually is saved with 12:00PM(UTC).
For display the timezone of the user is applied.
So the save value 12:00(UTC) will be displayed for me as 16:00PM. This will not change as Dubai does not use Daylight Saving Time(DST).
My family in Germany will see 13:00PM for a date in winter (Central European Time/CET - UTC+1),
but 14:00PM for a date in summer (Central European Summer Time/CEST - UTC+2).
Using the workaround does not take the timezone into account.
There is a way (another workaround) to figure out your timezone using the difference of Date vs. DateTime database fields (see below).
But as you already mentioned this might be a bigger effort.
If you still have the option, try to move all your date/time information to Airtable.
This way you can do all the date&time calculations Adalo does not offer using Airtable Formula, including the option to deactivate timezone conversion, first day of the week, month, weekday …
But be aware that there are other restrictions with the Airtable integration such as paging (max records returned) or Lookup fields.
Workaround to calculate user timezone offset
- Save the “Start of the day” to a database field of type Date in the User collection
2. Calculate the time difference and save it to the user collection as UTC offset
