Small and medium business | Business Central, N...

Inconsistent date values when pulling timezone-independent fields from Dataverse virtual table

(6) Share

Report

Posted on by SS-23091538-0

Hi,

I am facing inconsistency in date values while pulling data from a Dataverse table using a virtual table.

The field in the Dataverse table is defined as timezone-independent (so it should only return the date value).

For example:
- If the datetime stored in Dataverse is 21/09/2025 11:59:59 AM, the virtual table returns the correct date: 21/09/2025.
- But if the datetime stored in Dataverse is 21/09/2025 12:00:00 PM, the virtual table returns 22/09/2025 (the date is rounded up by 1 day).

After testing multiple cases, I observed:

If the time part is in AM, the returned date is consistent.

If the time part is in PM, the returned date is shifted to the next day.
There is no impact of Time-Zone Configuration.

I cannot change the field property in Dataverse because this table is synced from F&O HR via dual-write.

My questions is:

Is this rounding behavior (AM = same day, PM = next day) expected when Dataverse converts a datetime field to date in a virtual table, or is this a bug/limitation?

Thanks in advance for clarification.

I have the same question (1)

All responses (6)

Answers (0)

Nimsara Jayathilaka. 4,950 Super User 2026 Season 1 on at

Like (6)

Report
Copy link

Link copied!

Hi

Yes, the behavior you're observing—where Dataverse virtual tables return the correct date for AM times but shift by one day for PM times—is expected and stems from how Dataverse handles time zone-independent date fields.

Dataverse stores all date and time values in UTC. When a field is set to Time zone independent, it stores the exact date and time without converting to the user's local time zone. However, when this data is retrieved and displayed, Dataverse applies the user's local time zone settings. If the time stored is near midnight UTC, the conversion can cause the date to shift to the previous or next day, depending on the user's time zone.

Refer : https://youtu.be/hieySh3Rlxk

Thanks

Nimsara

1 people found this reply helpful.

Was this reply helpful? Yes No
SS-23091538-0 22 on at

Like (2)

Report
Copy link

Link copied!

Hi @Nimsara Jayathilaka.

Initially, I had the same understanding. Since the user settings in Business Central are set to UTC, I expected the date to match exactly with the value in the Dataverse entity.

Based on this assumption, I ran several test cases. What I observed is that for times in the AM, Business Central retrieves the same date as stored in Dataverse. However, once the time shifts to PM, Business Central starts retrieving the next day’s date.

My current assumption is that Business Central does not support datetime fields with a time zone–independent property. The purpose of time zone–independent fields in Dataverse is to focus on the date portion, not the exact time. Accordingly, Business Central only pulls the date portion from Dataverse's datetime field, and there's likely some translation logic that causes the date shift when the time is in the PM range.

Was this reply helpful? Yes No
Suggested answer

YUN ZHU 99,086 Super User 2026 Season 1 on at

Like (2)

Report
Copy link

Link copied!

Hi, I suspect it has something to do with the following settings, which cannot be changed. . . .

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/webservices/managing-time-zones-with-web-services?wt.mc_id=DX-MVP-5004336

So sometimes we need to convert.

For example,

Dynamics 365 Business Central: How to easily convert DateTime between UTC and local time (UTC Time Zone Converter)

https://yzhums.com/59934/

Hope this helps.

Thanks.

ZHU

Was this reply helpful? Yes No
Suggested answer

Rishabh Kanaskar 6,219 Super User 2026 Season 1 on at

Like (5)

Report
Copy link

Link copied!

Hi,

This looks like a known limitation rather than expected behavior. In Dataverse, when a DateTime field is marked as Time Zone Independent, it should simply strip the time portion and return the calendar date. However, when virtual tables read the value, they often internally convert the field to UTC before truncating the time.
Because 12:00 PM (and any PM time) is effectively shifted to the next day in UTC for some regions, you see the date rolling forward by one day. This is not configurable at the virtual table level.

Recommended steps:
> Verify the field’s behavior directly in Dataverse (through Advanced Find / Power Apps table data). If the date there is correct, this confirms the issue is only on the virtual table projection.
> If you cannot change the field property (due to dual-write), consider transforming the date on the consuming side (e.g., through a Power Automate flow, plugin, or a calculated column) to ensure the date is consistent.
> Log this as a support ticket with Microsoft – this behavior has been reported by other users and is being tracked as a bug in some cases.

Thanks

Rishabh

Was this reply helpful? Yes No
Suggested answer

Pallavi Phade 5,420 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Namaste ,

Check Time-Zone Settings in Dataverse for that specific user

If all possiblities are tested and no results , then Would recommend to raise a support Ticket to MS for further actions . Y

Regards

Pallavi Phade

Was this reply helpful? Yes No
Suggested answer

Sahan Hasitha 2,683 on at

Like (3)

Report
Copy link

Link copied!

hi

The AM/PM shift you see is not expected behavior for a timezone-independent date field in Dataverse — it’s a limitation/bug in how virtual tables convert datetime to date. AM values keep the correct day, but PM values get rounded up to the next day. Since the field comes from F&O HR and can’t be changed, the workaround is to adjust the value on the BC side (subtract a day if needed), or fix it during sync with Power Automate/plug-in. Updating to the latest BC/Dataverse CU is also recommended.

Was this reply helpful? Yes No