You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Describe the bug
Datetime values are stored in SQL in UTC, as we all know. We also know that the clients (both Windows and Web) always show datetimes in the local timezone.
In order to work with and correctly evaluate the actual data, however, I would expect the debugger to show the datetimes in UTC, so we know the actual values going through the system. However, the debugger also shows datetimes in local time zones.
It needs (an option) to show datetimes in UTC and (preferably) in a yyyy-MM-ddTHH:mm:ssZ format.
2. To Reproduce
Steps to reproduce the behavior:
Set breakpoints and Watches on any table with a datetime;
Start a debugging session and trigger a process that passes your breakpoint
Note that the datetime is in local timezone
This is a snippet from Codeunit 10 - TypeHelper that you can use
Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (i.e. .gif) is not sufficient.
3. Expected behavior
I expect the debugger to show the data in raw form, i.e. datetimes in UTC yyyy-MM-ddTHH:mm:ssZ format.
4. Actual behavior
When I use a datetime 11/29/22 10:00:00 AM in the client, it is stored (verified by Format(TheDateTime, 0, 9)) as 2022-11-29T09:00:00Z since I am working in W. European Time (UTC+1). The debugger, however, still shows it as 11/29/22 10:00:00 AM
5. Versions:
AL Language: 10.0 and prior
Visual Studio Code: 1.73.1 and prior
Business Central: 21.1 and prior
List of Visual Studio Code extensions that you have installed:
-- AL Language
-- AL CodeActions
-- AL Object Designer
-- AL Variable Helper
-- AZ AL Dev Tools/AL Code Outliner
-- BusinessCentral.LinterCop
-- ErrorLens
-- Git Blame
-- Git History
-- GitLens - Git Supercharged
-- PowerShell
-- Waldo's CRS Language Extension
Final Checklist
Please remember to do the following:
Search the issue repository to ensure you are reporting a new issue
Reproduce the issue after disabling all extensions except the AL Language extension
Simplify your code around the issue to better isolate the problem
The text was updated successfully, but these errors were encountered:
1. Describe the bug
Datetime values are stored in SQL in UTC, as we all know. We also know that the clients (both Windows and Web) always show datetimes in the local timezone.
In order to work with and correctly evaluate the actual data, however, I would expect the debugger to show the datetimes in UTC, so we know the actual values going through the system. However, the debugger also shows datetimes in local time zones.
It needs (an option) to show datetimes in UTC and (preferably) in a yyyy-MM-ddTHH:mm:ssZ format.
2. To Reproduce
Steps to reproduce the behavior:
This is a snippet from Codeunit 10 - TypeHelper that you can use
Note: Because the developers need to copy and paste the code snippet, including a code snippet as a media file (i.e. .gif) is not sufficient.
3. Expected behavior
I expect the debugger to show the data in raw form, i.e. datetimes in UTC yyyy-MM-ddTHH:mm:ssZ format.
4. Actual behavior
When I use a datetime 11/29/22 10:00:00 AM in the client, it is stored (verified by Format(TheDateTime, 0, 9)) as 2022-11-29T09:00:00Z since I am working in W. European Time (UTC+1). The debugger, however, still shows it as 11/29/22 10:00:00 AM
5. Versions:
-- AL Language
-- AL CodeActions
-- AL Object Designer
-- AL Variable Helper
-- AZ AL Dev Tools/AL Code Outliner
-- BusinessCentral.LinterCop
-- ErrorLens
-- Git Blame
-- Git History
-- GitLens - Git Supercharged
-- PowerShell
-- Waldo's CRS Language Extension
Final Checklist
Please remember to do the following:
Search the issue repository to ensure you are reporting a new issue
Reproduce the issue after disabling all extensions except the AL Language extension
Simplify your code around the issue to better isolate the problem
The text was updated successfully, but these errors were encountered: