By Veronique LengelleDate and time has always been difficult to manage in many areas like SharePoint and/or the Power Platform. It’s not uncommon for a Copilot agent to get the wrong date. And that could have serious consequences depending on your processes.
It might be that the agent is returning the correct format but interprets the numbers wrong, doesn’t respect the users locale, or for some reason, gives you a completely random date! And that’s regardless of the agent’s model you’re using… The weird thing is, it might have been working fine before, and the issue appeared out of the blue without changing anything.
So in today’s post, let’s see potential root causes and how we can counter this.
Settings to check
Before implementing any sort of solution or workaround, a few settings can be checked:
- Profile: Check profile settings in Microsoft 365. Under Settings & Privacy, look at display language, regional format, and time zone.
- Outlook: Check the calendar time zone.
- Power Platform & tenant: Check the users and tenant settings
- Copilot agent: When the agent was created, did you expand the “Agent settings” and update the language?
- Copilot Credits: Make sure Copilot credits are assigned
- Browser: Check language settings
- Computer: Check time, region, and time zone
Here are a few links to help further:
- Copilot Studio regional settings including supported locales and formats
- Accommodate Time zones
- Noda Time (for time zones)
What’s happening?
After checking all the above settings, what I experienced myself was either a random date, or clearly an issue with the en-US and en-GB format. For example, 07/05/2026 is the 7th of May in UK format. But the agent kept on giving me the 5th of July 2026… Clearly looking into the future!
As I continue to troubleshoot further, including adding instructions to “force” the agent with a specific format, it didn’t help either.
Then I started looking at the agent settings; my agent had both Knowledge settings turned on.
What I did notice is, I’ve got a better output when Allow ungrounded responses was turned OFF. But what if you need that setting turned ON then? Well, in my case, using Power Automate helped mitigate the problem.
Solution / Workaround
To make sure the date is accurate (simple scenario, only UK time zone), let’s create an agent flow, and use the Convert time zone action. You may have to perform a hard refresh (I always do) and adjust your instructions as well.
For more complex scenarios, you may look at modifying the system variables Conversation.LocalTimeZone and Conversation.LocalTimeZoneOffset in a topic.
Then, return the output of the Convert time zone action to the agent.
Now the correct date is returned, plus some more information 😅
Conclusion
This is a frustrating issue that may appear all of a sudden (at least for me), but I hope it helps mitigate the problem if you face it.
Thanks for reading! 🙂