How can we improve the newest version of Windward Studios Products?

Expand date parsing to other standard formats

Currently, AutoTag is able to parse dates stored in ISO format (e.g. "2017-09-12T00:00:00.000Z" stored with the toISOString JavaScript method) without any additional input from the user beyond specifying a date output format and type. However, it throws an error when other standard formats are used, such as that generated by the toDateString JavaScript method (e.g. "Tue Jan 12 2017 00:00:00 GMT-0000 (UTC)"). A workaround may be to spell out the format in the Input attribute on the tag, but this is cumbersome and not user-friendly. It would be better if AutoTag natively parsed standard formats other than ISO.

9 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Brent R. shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Evan Kawa commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    Hi Brent,

    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.

    During our review though our lead developer said that the Javascript method toISOstring should solve this issue for you. Take a look at the toISOstring Javascript method and let us know if that suits your needs. Here is some documentation that may help:


Feedback and Knowledge Base