Hi there,
I got a strange behavior with both the datetime input and the datetime picker.
I have some data values (startdate, enddate, limit) stored within a database loaded into session vars on Session startup event:
script funct ex: user_settings.loadUserSettings(session)
these vars are loaded and set correctly to session customs.
session.custom.user_settings.start_date_param = [databasevalue]…
I bound a label within a view (columns) on one session var and it displays the correct database date on session start.
Then, I bound a datetime input to the view on that same custom session var (bidirectional), the datetime display nothing at all, empty, nada.
I started a new project from scratch to make sure the behavior is the same with a fresh view, the same thing happens here.
This is not the behavior I expect from a date picker.
2 days lost on that odd behavior. The date displayed by the label: 2020-03-03 15:28:51.601+00
Is this a date casting problem? A real bug?
Thanks for your help!
Stephane.
It sounds like you’re using an older version, but DateTime Inputs require a datatype of date or an integer value; the string from your SQL query is most likely resulting in a warning in the Property Editor (maybe not on older versions, but it definitely will on newer versions). Since the bound value is not a format it knows how to do anything with, the DateTime Input won’t display anything.
You could try transforming the binding with a toDate expression:
toDate({value})
but your supplied formatted string failed to be converted with that expression. Perhaps you could format the returned query value in a format the expression recognizes?
I’m using an 8.0.13 nightly version and I can confirm that the DateTime Input does display bound values as long as they are a date type or an integer. In the following screenshot, the incoming original value from the binding (parent.custom.key) is a string (“2020-1-31 12:00:00”) which is then cast as a date datatype, which the DateTime Input understands how to represent. The extra nanoseconds are a result of the format I have in place at DateTimeInput.props.format as I was attempting to replicate your format.
2 Likes
Finally the problem came from the date format on the database. You saved my day!
Thank you for the quick reply!
Stephane
2 Likes
