Hi everyone, I created an Action in my app that adds a certain amount of time to a Start Date. I used this tutorial to figure out how to calculate/add times: Help : StarTIME +60 = funny Endtime 🤔 - #3 by karimoo.
Say my start date is 1/31/2021.
According to this tutorial, 1:00PM = 0.542 (since 1:00 is 780 minutes from the start of a day and 780/1440 = 0.542).
When I add 0.542 to 1/31/2021, I get January 31, 2021 1:00PM ( this is what I want).
I want to get the same time on 4/25/2021, which is 84 days later. But when I add 84.542 to 1/31/2021, I get April 25, 2021 2:00PM ( this is not what I want).
It seems to be pushing all my times 1 hour forward! Is Adalo accounting for Daylight Savings ending, or something else that I’m missing? And if this is the case - any way I could override this so I can continue to iterate my dates at the same time? Thank you!
Thanks @karimoo (and seriously appreciate the great ‘StarTIME’ post - it’s helped me so much).
Here’s some screenshots that might help explain what I’m seeing. Even when I add just 84 days to a date, I’m seeing it shift 1 hour forward after 3/14 (which is when Daylight Savings ends this year).
The button adds the second value (days) to the selected Date in the first field:
The answer should be Date at 12:00AM, but here it shifts to 1:00AM. Would love to override and ignore daylight savings completely. The backend Actions I have just iterate days from a certain Start Date, and I can’t have the time re-adjusted at each iteration (just not feasible with the volume/number of iterations I have).
@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
Wow, as always @karimoo such a wealth of knowledge to unpack here. Both ideas have their own pros, and I’ll have to look into each one more. I personally haven’t used Airtable before, but it sounds like it may offer some extra formulaic flexibility.
this is what I want).
this is not what I want).
)
