Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!
The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.
Hi All,
We have just upgraded to Appian 20.4. I am not sure if the issue due to this but facing very strange scenario when using todate() function in an expression.
Discussion posts and replies are publicly visible
I do not have a 20.4 environment handy, but can confirm this expression returns false in both 19.4 and 20.3.
On what grounds would you expect this comparison (comparing a date value, which at the end of the day evaluates to an integer, versus NULL), to evaluate as FALSE?
despite the fact what we would expect as a result out of this expression. I can confirm the behavior: in version 19.4 it renders to 'false' in version 20.4 the expression renders to 'true'.
I guess we have to evaluate our application code for the cases were a null would be passed into the 'todate' function and check if some decisions or branching is based on that.
Would be nice if the Appian Product Team could shed some light on it about their thought process.
I'm in 20.4 and I can confirm that tointeger(todate("08/01/2021")) returns a value of "-4901". (I'm curious what it results in 20.3 or earlier.)
So if the comparison operator assumes "null" has an inherent integer value of zero, then the current result is as expected. However in the past I've found that using any such value comparison against NULL values is unpredictable and not recommended.
In 19.4 tointeger.. returns the same: '-4901'. And I agree, it is not best practice to compare against null. But we run in some cases where a connected system changed its behavior because the C# framework was updated. It returned null in date fields instead of blanks. You know the rest of the story.
yeah i feel you. my high-level "appian approved" answer to this (and also my preferred solution personally) would be that if you will be comparing two values and you need to gracefully handle the scenarios of one or the other of the values coming back of null in a predictable way, you would be advised to create an expression rule that explicitly handles the different use cases.
I'd suggest opening a ticket with Appian Support.