Breaking Feature - Honeycode Randomly Using Different Timezones to Dates Field

Hi there!

I have been developing with Honeycode for a while now, and my team uses it on a daily basis.

I have not made any changes to my interface or tables, but the dates in my table display differently on different pages (off by 11 hours exactly on some of the screens). Has there been a patch to Honeycode recently (in the past 48 hours) in relation to dates?

For more context, see below example of two lists reading the same value in the same table:

Interface 1

Interface 1 Implementation

Interface 2

Interface 2 Implementation


These two values are definitely reading the same row of the table (identifiable the dummy attribute I have added, hello world), which reads the following row:


This is absolutely driving me nuts and bugs like this is one of the major turnoffs for developers working with more complex queries on Honeycode.

UPDATE: I have noticed that the incorrect time being displayed is UTC time, which is Honeycode's default timezone. Is Honeycode perhaps converting my timezone (AEST) to UTC automatically (and only under certain circumstances)? Again, I have been using my application for months now, and this has never appeared as a problem.

I am facing the same issue.
I have a hotel check-in and check-out sheet manager for my clients and when I select a 24-12-2021 as the date it is storing it as 23-12-2021.

I suppose when I select only date, it is saving default time as12:00 AM and I am in Indian Time Zone so 24-12-2021 12:00 AM in IST would be 23-12-2021 6:30 PM in UTC date.

Is there an urgent solution to this because it is saving data in a wrong way.

For reference see below picture

In View Mode it is showing Wrong Date (In database also wrong date stored)

In Edit Mode it is showing correct date

1 Like

Glad to hear that I'm not the only one. @Nira-c595 - since when have you been facing this problem?

We have just spent the whole day fixing our dates data thinking we entered them in incorrectly. Now we have half of our dates in UTC, and the other half in AEST...absolute disaster, considering Honeycode does not provide an option to backup our data easily.

I have been facing this issue since today morning. So approx since 2-3 hours. I also thought it was our internal data entry issue but thanks to your post, I realized it's a system issue and hence we have not changed any old dates, still data entered today is stored wrong, so that will need to be fixed.

Hope this gets fixed asap.

1 Like

My employees first reported the problem 4 hours ago, so the timeline adds up.

A temporary fix I can think of right now is to:

  1. Revert any date fixes made so far
  2. Manually offset the incorrect date fields by appending +11/24 (or some other value, based on your timezone), then removing this manual offset once the Honeycode team gets onto this.

Yes, that's an option but my issue is How to add that +5.5/24 in the update page?

Because on my Edit page the date field is "Shared Type" and not "Variable" so can't perform an operation of "+5.5/24 on that.

Ahh that is true. :confused: You could run a periodic automation triggered every x minutes to update those values in the table directly? Not the most elegant solution, but it's one which comes to mind.

It looks like the problem is now fixed (at least on the mobile app). Thank you for patching this up so quickly, Honeycode team! It’ll take some time to fix the data and yesterday has been a stressful day, but it’s not the end of the world.

Dear Honeycode team, could you kindly provide an update on what the breaking change was so that the community gets an insight into the steps being taken to prevent this from happening again?

UPDATE: Nevermind. Problem is still persisting on the desktop copy of the Honeycode application.

Hi @Eric and @Nira-c595,

Please accept my apologies for any inconvenience.

Is there an offset calculation in your tables that is causing this date/time accuracy issue?

On my end, I tried to replicate the issue. The goal was to save a date from a screen into a table and read the same date from the table into another screen. There were no problems. Is there any other another expression or formula in your application/tables that is contributing to the time change.

Please let me know if my understanding is incorrect.

In Honeycode, all dates and times are in UTC, which may require a simple conversion to set up notifications in your local time zone. UTC-time-zone-conversion article could be useful to review for better understanding.

Hi @Pankaj,

No code changes were made to my application, so I don't believe this is a problem with any formulas I am using, and I am well aware that Honeycode uses UTC time only. In fact, the problem only occurs on the desktop version of my application, and the mobile version.

See below:



As you can see above, the code used in both the desktop and mobile version are fully identical.

Not quite - the problem seems to occur depending on the way a list is generated. I'll try to do a minimal reproduction to help resolve this case. If this is indeed a bug, this is a huge problem for us international users.

Update to above: I have been unable to reproduce the situation in a minimal setup. I'm not exactly sure what is triggering this new bug (no code change was made to trigger it). @Nira-c595 - could you share your code for the screenshotted lists? It might help with figuring out the trigger for this bug.

My issue is still not resolved. The data getting stored in the table is incorrect. If I select 24-12-2021 from the date picker, in the database table it is saving it as 23-12-2021

Screen 1:
Data in View Mode (Wrong Data)

Screen 2:
Data in Database Table (Wrong Data)

Screen 3:
Data in Edit Mode (Correct Data)

Screen 4:
Screenshot of Formula (It's Pretty Straightforward, I am just calling the column, not using any formula on it)

The issue is I only have a desktop version so not able to verify the same issue in mobile.

But this is giving a lot of issues because our complete process is on dates and they are not getting stored correctly.

Update: Just to recheck any app-specific bug, I created a new app with only one table and 1 column of Date. I created an app screen to add and edit and it is still storing the wrong data in table and in view mode.

Screen1: App Builder Screen of New App built for tracing the bug

Screen2: Web App View

I changed the time zone in my computer to UTC and now it's storing data correctly. @Pankaj is there a system in honey code that if I only select date it will check from my computer which timezone I am in and then convert it to UTC? Because we have been using this system for quite a long time and never was honey code checking our computer local time zone.

1 Like

I believe the problem lies with the source of the column list, rather than the code for the field itself. Regardless, this unfortunately doesn't seem to be something that can be fixed safely on our end, @Pankaj. :slightly_frowning_face:

This is my precise train of thought also. The bug I am experiencing is definitely identical to @Nira-c595's, and I think there must have been some change to Honeycode wherein the local time is used instead of the UTC time.

Hi @Eric and @Nira-c595,

I appreciate your response and information provided.

Thank you @Nira-c595 for submitting the issue report.

@Eric I'd appreciate it if you could submit an issue report as well. Issue report would help us diagnose the issue.

You can rest assured that I have brought the issue to the attention of our engineering team and they are reviewing it.

1 Like

Hi @Pankaj - your quick responses are much appreciated. I'm submitting an issue report now as well.

UPDATE: Unfortunately, the usual Issue Report Button does not seem to pop up for me:

Hi, looks like the problem is fixed. I am able to save the dates correctly. @Eric is it solved for you also?

1 Like

@Nira-c595 yes, you are correct, issue should be resolved now. cc: @Eric

Thanks for reporting and let us know if anything else comes up!

1 Like

Fixed for me also! Thank you for your contribution @Nira-c595, and appreciate you getting on this quickly @Pankaj and @aj. Much appreciated.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.