Hi Duane,

I would recommend double checking that the field display type is set to Date and not Datetime in the Data Source Object field settings. Alternatively, you can override the field metadata to Date in the model on your page.

What’s happening here is if the field type is set to Datetime Skuid interprets the Date as midnight UTC on the given day, then adjusts for the user’s timezone which may result in the previous day being displayed. Switching the type to Date should prevent this.

Thank you for your response. I have double checked and the Skuid datatype is Date (not Datetime) in both the datasource and the form element. The issue remains.

The other thing to confirm is the time zone settings on your computer, and in your user record (for the Skuid Site). If these are not aligned - we have seen strange behavior.

Thanks, Rob. These have all been checked and the behavior remains. I was on a call with Skuid today and they are working on a fix or workaround. If anyone else is struggling with this, there are a few things that can help. If you aren’t using any date/time fields, set all the skuid users to Casablanca (UTC time) and the dates will behave correctly (but your datetime will not.) If you only need to display the date field and not edit it, you can use a formula to the date field and the formula date field will render correctly. At the moment, the table component is showing the incorrect date and the form component will show the correct date until you click to edit and the date picker will show the incorrect date. The good news is, the correct date is in the database.

Sorry about the problems here. I’m reminded of this image that went around a while ago:

Core of the problem is that SQL dates are being incorporated into Skuid with a Time segment that looks like this:

2017-11-13T00:00:00.000Z

Instead of just
2017-11-13

When Skuid finds that Time segment its assuming the value is UTC and is offsetting the value according to user time zone. Boo.

This is a bug in our new V2 page API and we are looking to fix it. But here are some workarounds - beyond the ones you mentioned above.

1. You can force the entire page to run in a particular time zone. This means the user doesn’t have to reset time zone for other things. But it causes problems if you have other date time fields on the page. Add a Javscript resource to the page (Category Generic JS) with the following code:

(function(skuid){

	var $ = skuid.$;

	$(document.body).one('pageload',function(){

        skuid.time.setUserTimeZone("Europe/London")

        .then(function(){

           console.log("Time Zone has been set to London - or UTC!");

        });

	});

})(skuid);

2. If you remove the time component from the field value in all the rows in the model - the correct day will show. You can do this in code, or you can do it with a model action that is triggered every time the model is queried or saved.
   
   The action will “Update Rows” - updating all the rows in the model, targeting the date field, and using a formula that looks like this:

LEFT({{{dateField}}}, 10)

The down side to this strategy is that the model will detect changes and the “Modified” state will display. You can fix this with a variant in your design system. But your Save and Cancel buttons will always be one.

Once again - sorry about this, and we’ll be fixing it as soon as we can.