Time (and Data) datatype vs Web Services in SaaS

Personally, I have fumbled on & off in attempts to use Time datatype and its AL related statements within the application to establish record differences and offsets. Last time, it was just yesterday, considering OData calls in a PowerApp scenario.

If you are normally working with Dynamics 365 Business Central online through Web Clients AND Time Zone is unique for all of them in the application, there is no problem. Everything is fine. All happy chaps. The Date and Time entities will be all consistent. But in this truly (madly, deeply) connected word, sooner than later you will have to develop an integration extension or purchase one from the marketplace. This will establish the usage of Web Services, and this is where problems might start.

For Web Clients, when the time or date variable is retrieved, it matches the current session Time Zone set in the application and so these are stored and displayed.

For Web Services, the platform always set them with their equivalent UTC values, regardless of any user personalization, Time Zone settings included.

There we go: apples and bananas.

The rationale behind this is that for an external system integration, calling a Web Service must be consistent and not be dependent on any kind of user personalization. For instance, the same call for a user located in Maui, with a Time Zone set to UTC-10, must be identical to the same done by a user located in Brisbane, with UTC+10.

If you do not want to smash your heads many times in trying to solve these issues, the datetime datatype must be used in advance in your design to handle time (and date) consistently when retrieved from different client types.

By storing a datetime, it is possible for the platform to convert the value to the user Time Zone of choice and show it consistently in the client. The Hawaiian will see, then, the time in his time zone (UTC-10) while the Aussie will do the same as well (UTC+10). Needless to say: daylight savings will also be handled by the platform accordingly.

Let’s get into a practical example with few lines of code: small sample as proof of concept can be downloaded here: https://github.com/duiliotacconi/DT.AL/tree/main/APITime

I am thrilled… my first lines of code in my blog post (– I will start IMMEDIATELY with a myInt : integer; 😊 -). Do not blame me, I made it to explain the concept as simple as possible.

TABLE STRUCTURE

        field(1; “Entry No.”; Integer)

        field(3; “Time as Text (UTC)”; Text[100])

        field(4; “Time as Integer (UTC)”; Integer)

        field(5; “DateTime”; DateTime)

        field(6; “Description”; Text[100])

        field(8; “DateTime ISO8601 (UTC)”; Text[50])

        field(9; “Date as Date”; Date)

        field(10; “Time as Time”; Time)

TRIGGER

    trigger OnInsert()

    var

        TypeHelper: Codeunit “Type Helper”;

    begin

        “DateTime Result” := CurrentDateTime;

        “DateTime ISO8601” := TypeHelper.GetCurrUTCDateTimeISO8601();

        “Time Result” := ExtractTime(“DateTime ISO8601”);

        “Time Integer Result” := GetTimeAsInteger(“Time Result”);

        “Time as Time” := Time();

        “Date as Date” := Today();

    end;

So far, so good. Just deploy the simple extension and perform the following actions:

1. Change Time Zone in My Settings to Hawaii (UTC-10) – see below – and add a record manually in Time Zone Entries page.

2. Change Time Zone in My Settings to Brisbane (UTC+10) and add another record.

3. Use whatever client you like to make a POST call to the API page published (for an example, see below):

POST https://api.businesscentral.dynamics.com/v2.0/<tenantId>/SandboxUS/api/dt/demo/v2.0/companies(<companySystemId>)/timeZoneEntries

Body

{

    “Desc”: “API POST from Somewhere”

}

And this is the result:

Date and Time: Apples and Bananas.

DateTime: consistently in UTC and always displayed in local client Time Zone (Brisbane, in the example just shown).

CONCLUSION

Use Datetime datatype as much as possible in your application layer instead of Time datatype. Overall if you have planned or even just smell that there could be any possibility that your code could be used by Web Services. This will help you save headaches and… Time.

My personal opinion:

Time datatype should be banned from cloud-ready development since most probably these will be used to perform time calculations or time differences. Dates should be handled carefully, considering the above scenario, whenever there are integrations of any type.

AND/OR

Microsoft provides API (or an easy way) to manipulate Web Services Time Zone with Dynamics 365 Business Central online.