for creating a record for a single day.
I do the same thing he does, first using a button to set a temporary variable for the user “TMPcurrentDate” = start of today, and this brings the user to a new screen. (action: Update User, TMPcurrentDate, Start of Today)
TMPcurrentDate can then be advanced or rewound so a user can make an entry on a specified date.
My issue -
For some reason to get mine to work correctly, adding +1 (on the right arrow) does not increase tmpCurrentDate by 1 day and subtracting 1 does not decrease by one day for the left arrow, instead it rewinds the day by 2 days!
Instead, I need to do tmpCurrentDate+2 to increase the day by one (right arrow) and then tempCurrentDate-0.5 to decrease the day by one (left arrow)
Then when I create the record for the day, I need to enter User tmpCurrentDate +1 for the date in order for it to record the correct day.
Any ideas? Is it a time zone issue perhaps?
This is an issue because I have one tester who is in a very different time zone from me (New Zealand vs USA) and we are experiencing an issue where the records he creates are always a day ahead. I’m thinking this is a result of me adding tmpCurrentdate+1 in the create records, but the problem is if I don’t use the +1 then when I test the app, the date is one day ago.
Edit to add info: TMPcurrentDate is of type “Date”, not “Date and Time”
First of all: are you sure your Tester isn’t 1 day ahead in reality? San Francisco is 21 hours behind Wellington
Second: in order to add / subtract days you should use +1 / -1. Dates× are stored as number of days since 1/1/1970. You may get correct result when subtracting 0.5 but this may happen only to date/datetime rounding flow.
Third: Adalo has adjusted the logic for date/datetime quite a few times since I’ve made this video. The general logic is correct but some details may (or may not) work differently.
As I remember, when you use date, it should store the value in the GMT+0 timezone (so that there are no decimals if you convert this to a number). However, it seems that this transition is done only on a final step when the value is stored to the database (or maybe even on the database level). So one of the ways to debug this is to add text labels and display each calculation step. Also you may try to store the date as a number, operate with a number and then convert it back to date.
Keep in mind that making this work in PWA doesn’t mean this will work correctly on iOS and Android, a separate testing is required. The reason is that iOS / Android may return StartOfToday differently from PWA (at some point of time I’ve seen iOS returning it in full datetime format - assuming that the app will take care of the rest).
Thank you for the reply and excellent explanations as always @Victor !
The issue is the tester is 1 day ahead in reality often - but the recorded entry would be 2 days ahead, even when the displayed tmpCurrentDate was correct.
Second: in order to add / subtract days you should use +1 / -1. Dates× are stored as number of days since 1/1/1970. You may get correct result when subtracting 0.5 but this may happen only to date/datetime rounding flow.
The problem is that adding or subtracting 1 to change the date for me never seemed to work - I would always get the wrong day back.
Regarding storing the date as a number:
A question - if I store the date as a number, how do I convert it back to date to display, or to use in calculations for logic?
EDIT: I see some good guidance here: How to calculate with days and minutes - #6 by Yongki
I will try converting to DateTime format and see if that works – that adds an issue, though because of the conditional visibilty for the “add record” button. I did have that display (like your tutorial) only if count of daily records, with the filter
Current Daily Record → Logged in user is equal to Record ID of user
and
Date is equal to Logged in user → tmpCurrentDate
were both equal to zero.
How can I check condition 2 (date is equal to User tmpCurrentDate) with DateTime format vs Date? I only get options for is after, is before or is between.
My thought now is that I keep the current tmpCurrentDate and fill that with the new tmpCurrentDateTime variable so that tmpCurrentDate keeps the current day and I can still use that in logic.
Thanks again, I’ll update here if changing to DateTime format works.
My pleasure. I didn’t provide the full solution though :-/
I’d say, if you are using dates only - I would try converting everything to number, storing it as number and operating with it as a number (I mean limiting the number of entries per day). And then convert numbers back to dates (you can update date property with the number) when needed.
In your case somewhere there is a datetime conversion involved, and as datetime stores current TZ, this creates issues. Sorry, I don’t have an opportunity to replicate this now so can only give advices
In regards to visibility conditions - this never worked correctly to me from the beginning. It’s always a trial and error, and another error in the native build :-/. Always a pain for me and have to end up with some manual fixes
Frankly speaking, because of this I have never released several booking templates I’ve made, to the general public. Because date calculations are so fragile, I can’t imagine supporting such templates commercially. And I even didn’t start talking about summer time changes, timezones with 13hrs difference from GMT and so on
