Hi Ben -
You ask a GREAT question and to be honest, I’m not sure I have a good answer for you. Also, your question is making me re-think the entire flow.
The challenge with “automatically” setting the time regardless of timezone is that somewhere it’s going to result in a different date being displayed. My “gut” tells me that it should be set to 00:00 for the date specified in the users timezone since technically a DATE field actually does have a time portion set to 00:00. That said, guessing on behalf of the user is never a good idea 
Given the question you raised, I went back to my client to re-think what is really needed here. Originally, they asked “can we just show the date on Screen #1 & #2 and then the time on #3” and I said “oh yes, piece of cake, Skuid has this awesome new override metadata feature - boom done!” Well, I should have thought this through some more 
At the end of the day, we really need a “transaction date” & “transaction time.” The challenge that we have is that we have employees all over the world working on parts of the business throughout the globe. When they talk to a customer and agree “March 21”, regardless of who is viewing that data, it needs to show March 21st as that is what will get printed on legal docs, etc… Then, when they get to the time part of the business process and agree with the vendor “5:00pm on March 21” they will always be talking “local time in that physical location.” The physical location could be France but the user working on the system might be in Seattle with an SFDC time of PDT. This would require the user to do timezone math and set the date/time based on PDT since that is what their SFDC setting is. This would never fly with the business since they would constantly be doing timezone math for all regions of the world. Also, regardless of who is viewing the data, all “conversation context” should be “5:00pm on March 21” but if the data gets displayed as converted based on SFDC timezone, they’d see/read it as something different.
The short of all of this is that given my use cases, I think I need to have a separate date and time fields. Unfortunately SFDC doesn’t have a time field so I’m likely left with a text field that has validation for formatting, etc. Unless you or someone else reading this has other ideas?
What is really needed here (ideally at the SFDC level but could be done in Skuid) is a way to designate a datetime field with no timezone - just a “fixed datetime”. This would eliminate any conversion while still providing the standard datetime picker. Maybe there is a way to do this already in SFDC that I’m not aware of?
Circling back to your original question, I think if Skuid is going to support overriding datetime to date, 00:00 in local timezone is likely a consistent approach that mirrors how DATE field values are stored within the DB itself.
On a related note, in doing some testing to figure out some solutions for all this, I found another issue related to date/time conversion. I created “Datetime field not converting correctly based on user timezone setting” to track it.
Hope all my rambling is of at least some help
