Expand date parsing to other standard formats
We have reviewed this idea internally but it has been declined for development. The reason is that the workaround you named to specify the input format of the date is already the supported functionality. Because of this we are not focusing on further improvements to date input formats at the present time. Thank you for your suggestion, and please submit any other ideas you have to improve our products.
Evan Kawa commented
I know this is over a year old, but wanted to add that I have run into this as a major problem during my trial use of Windward designer. The dates in our database are all stored as unix timestamps in the form of seconds since epoch ('1552934481.816', for example). With the help of one of your people (Kelly) I was able to work around it in some cases using datetime() or strftime() functions, however using any of these in a select completely breaks the use of your wizards, which makes working with it very cumbersome and error prone. I would very much like to see this addressed, if at all possible.
Brent R. commented
Thanks, Adam. We're already using toISOString, as mentioned in the first sentence of my suggestion. As long as we can guarantee with 100% certainty that all of our developers and our customers' developers will always and only output dates in ISO format, we're solid.
FWIW, it's a bit surprising (and disappointing) that you're okay with AutoTag's lack of support for other standard date formats, which itself causes errors, and won't add something that at the very least is able to parse a standard date string. Wasn't suggesting you should support every possible variation out there, but it doesn't seem (from my end, at least) that it would add a huge amount of overhead and risk to support the output of the toDateString method, which is equally as predictable and consistent as toISOString. But what do I know? Thanks again.
Adam Jackson commented
My name is Adam Jackson and I'm a Product Manager with Windward.
After review, we are not going to add this as it would add a lot of layers of complexity to our product and opens us up to a lot of different errors, edge cases, and exceptions.