Skip to main content
Nintex Community Menu Bar
Solved

How to find a future date in a SharePoint list and report the results

  • March 4, 2025
  • 4 replies
  • 29 views
  • Translate

DavidAD
Forum|alt.badge.img+8

I thought this would be a simple thing, but apparently it’s not. I have a Scheduled start workflow that is supposed to run daily to read a SharePoint list and find any items that contain a date six weeks (42 days) in the future. The workflow ran today and reported no results even though I know there is one item in the list that should have been found.

The workflow uses an Add time to date function to calculate the future date: using the built-in Current date from the instance, it adds 42 days and provides a variable as a result (date format, not ISO 8601 text string). Then the workflow queries the list, using the conditions that the specific date column has value and matches the date variable.

When I run this, it finds no results even though, as I said, there is one item in the list that meets the conditions. I have a feeling this has something to do with the format of the Nintex date (which is in YYYY-MM-DD format and includes the time) and the SharePoint date, which is M/D/YYYY and does not include the time (nor do I want it to).

I’ve used a Log to instance details to record the data in the workflow. The variable produced by the Add time to date function today (March 4) is 2025-04-15T00:00:00.000Z. The value in the SharePoint list item is 4/15/2025. Apparently Nintex is not recognizing these two as the same date.

But how can I make it work? The Add time to date function has no option to change the date format. I don’t want to add a time to the SharePoint date column because I’m sure it would be the exact time the item was created - and then Nintex still wouldn’t find a match because it’s looking for a time of 00:00:00.000.

This seems like it should be a simple thing to do. What am I missing?

 

Best answer by DavidAD

Hi, ​@SimonMuntz - seems like you’re doing a lot of research for me lately. :) 

I've worked out a Rube Goldberg kind of solution that seems to be working. It actually involves converting the dates in Nintex and SharePoint to text and then comparing them. Then there was a time difference I had to account for, related (I assume) to our time zone vs. UTC. I’m sure there’s a setting I can change to account for that, but I couldn’t figure out where. So it’s worked into my solution by adding days and hours to the Add time to date step.

The above is obviously simpler, and I considered something like it at first, but I guess I assumed it wouldn’t work because Nintex is converting the date to a string and the SharePoint column is in Date/Time format. Also, the date in Nintex has that leading zero where the SharePoint date does not. (I wish the Format date to string function had an option for M/D/YYYY format.) But anyway, I’ll give your suggestion a try and use it if it works.

I have to say, no matter what, this seems far more complicated than it should be. Nintex ought to be able to simply compare dates in SharePoint like it can with text, numbers, etc., without having to add all this extra stuff. I may post something in Nintex Ideas.

View original
Did this topic help you find an answer to your question?

4 replies

SimonMuntz
Nintex Employee
Forum|alt.badge.img+22
  • Nintex Employee
  • 2452 replies
  • March 4, 2025

Hi ​@DavidAD,

If you just output a date from the Add time to date action.
 

And then format that date to match SPO. does that help?
 


Converted date: 2025-04-15T00:00:00.000Z
Formatted date: 04/15/2025

Translate

DavidAD
Forum|alt.badge.img+8
  • Author
  • Apprentice
  • 71 replies
  • Answer
  • March 5, 2025

Hi, ​@SimonMuntz - seems like you’re doing a lot of research for me lately. :) 

I've worked out a Rube Goldberg kind of solution that seems to be working. It actually involves converting the dates in Nintex and SharePoint to text and then comparing them. Then there was a time difference I had to account for, related (I assume) to our time zone vs. UTC. I’m sure there’s a setting I can change to account for that, but I couldn’t figure out where. So it’s worked into my solution by adding days and hours to the Add time to date step.

The above is obviously simpler, and I considered something like it at first, but I guess I assumed it wouldn’t work because Nintex is converting the date to a string and the SharePoint column is in Date/Time format. Also, the date in Nintex has that leading zero where the SharePoint date does not. (I wish the Format date to string function had an option for M/D/YYYY format.) But anyway, I’ll give your suggestion a try and use it if it works.

I have to say, no matter what, this seems far more complicated than it should be. Nintex ought to be able to simply compare dates in SharePoint like it can with text, numbers, etc., without having to add all this extra stuff. I may post something in Nintex Ideas.

Translate

MillaZ
Nintex Employee
Forum|alt.badge.img+21
  • Nintex Employee
  • 667 replies
  • March 17, 2025

Hi ​@DavidAD 
Has your question been answered? 

Translate

DavidAD
Forum|alt.badge.img+8
  • Author
  • Apprentice
  • 71 replies
  • March 17, 2025

Hi, ​@MillaZ - well, I worked out a solution myself, as I mentioned in my previous post. The suggested solution above is only part of it. I don’t know if this is the only way it can be done, but I ended up converting the date in the workflow and the date in the SharePoint list to text (in ISO 8601 format) and then comparing them that way. I also had to account for the time difference between my time zone and UTC, although I concede that there may be a different way to do that in Nintex (I just couldn’t figure out what to change).

I submitted an idea (CNV-I-406) about this. It just seems to be that it ought to be simpler than this to compare dates. With text, integers, decimals, choices, etc., it’s easy to do a one-to-one comparison. But not with dates.

Translate

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings