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:
Instead of just
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.
- 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:
var $ = skuid.$;
console.log("Time Zone has been set to London - or UTC!");
- 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:
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.