3

Creating a unix timestamp in AL code is usually pretty straightforward, but not when the code used by different client types. A webservice client is always in UTC and does not need any time zone corrections, while a web client session does. E.g.


OriginDateTime := System.CreateDateTime(DMY2Date(1, 1, 1970), 0T);

TimeZoneOffset := TimeZone.GetTimezoneOffset(OriginDateTime);

OriginDateTime := OriginDateTime + TimeZoneOffset;

exit((CurrentDateTime - OriginDateTime) div 1000)


We run into issues when a webservice client is started by a regular user (using authorization code grant flow). Such a user has a time zone offset, while the webservice client session is in UTC. The timestamp generated by code above would be off by the user timezone offset (that is actually only applicable to the web client). The client type can be determined using CurrentClientType(), but that doesn't help if you need a unix timestamp is in a background client that was created by either a web client or webservice client.


Idea: add a wrapper for the C# code below:


DateTimeOffset.UtcNow.ToUnixTimeSeconds()


This far more straightforward and always works, regardless of the client type. This could be added to codeunit "Type Helper".

Category: Development
STATUS DETAILS
Completed
Ideas Administrator

This feature will release with 2024 wave 2. It was developed as a GitHub contribution: Unix Timestamp by Wildrik · Pull Request #1853 · microsoft/BCApps (github.com)

The Business Central team.

Comments

W

The code fragment shared in the request doesn't work correctly if you work in New Zealand time zone.I would even propose to change the request and ask MS to add a procedure to BC that simply calculates the unix time stamp in reliable way and returns the correct integer value.

Category: Development

W

This idea can also be implemented in a DateTimeOffset wrapper codeunit in 3PL System. In that case, it would be suitable for open source contribution and I would be willing to suggest an implementation myself.

Category: Development