I think the screenshot is self explanatory. So we have a date field. It shows correct date on the web version. Shows incorrect date (one day backward) on the mobile app. Where as the calculated field on the same mobile app, shows the right date.
1 Like
Hi @Thaha,
Thanks a lot for your report! We’ll definitely take a closer look at this issue in detail. My first assumption is that it might be a timezone-related bug. We’ll get back to you with an update as soon as we know more.
Really appreciate you flagging this, and wishing you a great day!
Best,
Leo
1 Like
Hey Leo, Thanks for looking. Any update that I can pass on to the user?
2 Likes
Hi @Thaha,
We already started the analysis yesterday and have some first insights. The title looks correct because a Calculation field is being used, which converts the value into a text string. In that case, the time zone is no longer applied. For a regular date field, when it represents a calendar day, the time zone must be applied in order to correctly determine the date boundary — and that’s where the issue comes in.
So far we’ve confirmed this much, and now we need to debug further to understand exactly why it happens. Could you may provide us with the time zone where the error occurs in the mobile app? That would really help.
As a temporary workaround (not elegant, but it might help instantly), the issue could be avoided by including a time in the field setting — that way the value becomes time-zone neutral. Of course, our goal is to fix this properly so the time zone is applied correctly. Time zones are always a tricky topic, unfortunately.
Sorry again for the issue, and thanks a lot for your support!
Best,
Leo
2 Likes
Thanks Leo. That helps. User is based in the UK and so London zone. No other time zones are involved.
1 Like