Just to update on this. After further looking into it, the issue appears to be a bug on the date range filter when using a Date/Time field. Although I’m not sure what is causing it.

I found a workaround.

On the Salesforce object, I created a formula date field to pull out the date value from the datetime field.

The formula looks like: datevalue(your_datetime_field)

I selected “date” as the field type for the formula. This is to make sure Skuid recognizes it as a date field.

Add this new field to the model and use it for the date range filter.

The bug doesn’t seem to happen anymore after this.

Hopefully this helps those who may experience the same issue. And if there is a better way to do this, please do let us know.

This is happening for me too, except that it’s the filter end date and it jumps forward one day. For example, if “05/01/2019 - 05/31/2019” is selected, clicking “Apply” changes it to “05/01/2019 to 06/01/2019”

Maybe a timezone interpretation? I assume you’re somewhere in the U.S. based on the way you write your dates so between UTC-5 & UTC-8,  I’m UTC+10.

This is annoying because the data displayed adheres to the dates that were selected so the dates displayed after clicking apply are incorrect.

Thank you both for sharing details, we are looking into this.

Another update to this in regards to Ty’s issue. For us, the issue was stemming from the daylight savings time adjustment. So we also experienced Ty’s issue of having some dates move one day back or forward.

An updated workaround is this: DATEVALUE(LEFT(TEXT(Datetime_Field__c), 10))

Found here: https://success.salesforce.com/ideaView?id=08730000000ktpHAAQ

Using this formula fixed our issue.

Hopefully this works for you too.

Can you please provide an update? Joseph’s workaround (the updated one) is not working here, as the formula field still sets the date based on UMT rather than local timezone. The problem seems to be skuid not adjusting the soql criteria for the time zone adjustment of the specified filter date range. Building a workaround with skuid models will be a significant effort, but users might wait if a skuid fix is expected in a reasonable time frame. Thanks!

Hi Mike,

You are correct that the formula doesn’t work on all cases. What we did was subtracted some hours to account for daylight savings.

New formula: DATEVALUE(LEFT(TEXT((Datetime_Field__c)-(240/1440)),10))

Basically subtracting 4 hours from the datetime. I don’t know why it needed 4 hours, but that’s what worked. The issue this may cause is that a datetime log that is set to 3AM will be potentially changed to 11PM the previous day, making the data inaccurate once again. This works for us, but it may not for everyone as the needs may be different. I hear your issue stems from the Timezone, which is different from ours.

I’m any case, I’m still hoping for a better solution rather than doing workarounds - which can get frustrating.