Another problem with C/AL DateTime is that C/AL is a bit rude when it comes to System.DateTime: whenever C/AL compiler (or runtime) encounters a value of System.DateTime it’s automatically converted to C/AL DateTime.
When you combine those two problems, you get the following problem: even though System.DateTime is perfectly capable of handling time in both UTC or local kind, C/AL isn’t.
To prove this point, just run this:
MESSAGE(‘Current local time: %1\Current UTC time: %2’,SystemDateTime.Now,SystemDateTime.UtcNow);
It will show this:
And I am currently sitting in a UTC+1 time zone, mind you.
A few days ago I have published my PowerShell script that streamlines and automates deployment of control add-ins from Visual Studio. Over the past couple of days I have improved it a little bit, and fixed a few bugs, so here’s an updated version that is more resilient to your project structure, produces resource zips that NST not only extracts, but actually understands, and does a little more.