Hi All,
We just realised that our date of births collected from users are showing incorrectly when brought over from Bubble via Integromat to Monday.com via api.
Some investigation I can see a sample date of birth is in the bubble database like this:
12/16/2000 12:00 am
so I assume this is a time zone issue. The 2 users we just noted the issue for are in Vietnam and Malaysia, Actually I am currently in Vietnam but not sure what time zone our bubble account is set up for and not sure how to check? I use a UK credit card if that effects it.
In any case we sending the date over as dd/mm/yyy but choosing to use Users Time Zone so if for example we are set as GMT I assume this explains why it is going to the previous day. We can choose a static time zone and then just choose the same time zone that we are set to I think to resolve this issue? But not sure how to find our time zone that is set with Bubble.
Any guidance would be great!
regards,
Hi, @stephen.clegg
Since Bubble stores data/time data as absolute GMT timestamps I would suggest handling all the date/time data as GMT times and changing it to the desired timezone while displaying the date/time data on the UI via
myDateVariable :formatted as.
Cheers,
Ranjit
Thanks @blurapps I was just looking at this again. It seems to be a time zone thing. So I am seeing date of births (or anywhere where we are collecting a date but no time from user) show as mm/dd/yyyy 12:00am in the bubble db when the user is in my same time zone as us but for a user in a time zone 4 hours behind for example shows for us as mm/dd/yyyy 4:00pm so that it seems to be storing as mm/dd/yyyy 12:00am in the users time zone. This can and is in some cases changing dates when we pull the date out to Monday. DoB should be fixed. I am exporting by API the date of birth with these settings:
Other dates do not really matter if they change by a day by date of birth must stay the same.
I do not seem to have any option to change the timezone to GMT when storing the user chosen date with Date/Time Picker. So if the date is coming in lets say from Indochina as mm/dd/yyyy 12:00am then wouldn’t choosing GMT time zone push it back 6 hours and therefore a day earlier?
I am trying to work out a way that the day will never change.
I am quite stuck on this. I can see the date is correctly displayed in Bubble but by the time it gets into Integromat via API it has changed to the day before so that the date when coming in to Monday is also the day before.
I tried changing the date going out from Bubble via API to be GMT but that doesn’t change the result.
We just want the user to choose a date that is fixed and unaffected by time zone. Maybe I am misisng something but this seems wierdly difficult…
When you get just a date without a time - 12/16/2000 for example - Bubble stores this the same way it stores date+time data - so it automatically stores the value as 12am on 12/16/2000
The value coming in from the API should be based on something standard - so either a UNIX timestamp or GMT time, unless it is instructed otherwise.
For displaying this value, you can either format the date/time value to be mm/dd/yy - this will only show the date value.
Or you can do date/time value :extract and extract the date from the date/time value here.
With the timezone shift, the day might get shifted as well.
I think this is a classic problem of storing a retrospective date. Storing this as a timestamp (date/time) value may not be a good idea because it has the timezone built into it and that goes against the idea of storing a static date. Instead, I suggest that you store the date as a text (dd/mm/yy maybe) and parse it any time you need to display it in a human readable way. This will help keep it independent of timezone.
You can use the API to extract the dd, mm and yy values and then concatenate a text that gets stored in the DB.
2 Likes
@blurapps Thank you very much for this. All makes sense.
I will play about with extract and see if that helps because it will only take 10 minutes otherwise as you say I will look at saving it down as text. I will report back final solution as this may be useful to someone. Thanks. Hopefully later today.
1 Like
