Thanks for the bug report. We’ve seen this issue before. Obviously, we should not allow you to do this override if it causes an error. I do have a few questions about your use case for when we fix this.
1. What is the use case for presenting the user with a DATE ui control, but sending the data to a DATETIME field? Is it for when a single field has multiple uses for different situations? Or is it the case where maybe the page designer does not have control over the database structure? I’m just trying to understand this a bit better.
2. What timezone would be appropriate to use for the conversion in your use case? The running user’s Salesforce setting? GMT?
1) There are a few use cases: - We have a multi-step workflow where in the first few steps, only the DATE is known. However, as the workflow gets to completion, the time comes in to play so we need a DATETIME - We have some business processes where only the DATE is important except for in very rare situations where a DATETIME is required. - To save screen real-estate on certain screens where only needing to know the date is important (e.g. object tabs with tables).
Would you want it set to midnight in your user’s timezone? Or something like noon? The thing that scares me about midnight is that someone in the eastern timezone would view that value as a different day.
Setting the time to noon seems pretty arbitrary though. I’m a little concerned that users using this feature will not understand the implications of converting a DATE to a DATETIME and that “Just drop the time portion” isn’t really as simple as it seems.
Sorry to hijack this thread, But Ben’s answer, makes me wonder the following:
I would like our default Time in all Date/time fields to Show 12:00 PM (now it’s AM), is there a way to accomplish this?
(as well , the one complain I get daily regarding skuid, is the calendar , does not have a “now / today” button , like default salesforce calendar, if there’s any way, please let em know…)
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.
Regarding your questions/comments, I agree that having a “TODAY” button would be extremely handy. There has been discussion about this in the past (see https://community.skuid.com/t/date-time-field-input-field-too-small-auto-set-as-now). You should be able to write a custom field renderer that interacts with jQuery UI Datepicker and sets showButtonPanel=true as this would show the “TODAY” button. From there, you could override the appropriate datepicker internal method to get it to behave the way you’d like (the default behavior is to just scroll the calendar to the current day). Another option is to write a custom renderer using another datepicker of your choosing. Would be great to see Skuid have this as a stock feature but that would require Skuid moving away from jQUery UI datepicker to another library and/or rolling their own. Both have downsides - for the former, heavier page load for extra JS/CSS from additional library; for the latter, lots of dev/test time. All that said, would be a welcomed enhancement!
For the 12:00pm default, the only way that I can think of a solution for this one is to write a snippet that gets called on “row created” and set the datetime to 12:00PM of whatever day you want to be the default value (e.g. TODAY). Not the best solution in the world but the only one I can think of at the moment at least.
