29

Add the moment the UTC Handling BC consistent, e.g., if you call the Function => CalcRoutingLine.CalculateRoutingLine(Rec, Direction::Forward, false); from a Button or from a Web service on the same data it will produce different data (as long you are not living in UTC Time). It is also testable if you move your PC to another Timezone and run the CalculateRoutingLine funktion. Produces the same Problem, everything is recalculated with the Session of the User that is in a different Timezone then the rest of the BC data.


The Problem is that he CalculateRoutingLine is converting DateTimes with Offset to a Date and a Time with no Offset.


To solve this kind of Problems, we have the following Ideas:

  1. Allow the Web service to run in the same Timezone then BC is running in. We see this as the best option for now, because Idea No. 2 takes too long to make it in all areas
  2. You fix the all places where you convert date time with Offset to Date and Time
  3. Allow to start a JobQueueEntry by a function call. This would allow the Developer to execute the Code directly but in the Timezone of BC



As long, you do not come up with a Solution, no one can use the Function CalculateRoutingLine via Webservice. We from our side will split now the code that we first save every thing in Database and a Job that runs every 60 sec will check if there was a change in Data and will then execute CalculateRoutingLine => my developer soul burns in pain.



Category: Development
STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team

Comments

M

Sorry about the bad formatting in my reply, but it looked just fine before submitting... I hope you can read it anyway.

Category: Development

M

This is really needed when working with integrations.Every function that calls Today(), Time(), or are converting between DateTime and Date or Time could end up with very unexpected results!I believe we could add two more options to solve this:4. Add support for a new HTTP Header, called "X-Time-Zone" or similar, that sets the time zone for the web service session. This approach is supported by many other systems.5. Add support for the use of SessionSettings.TimeZone() in a web service session. In that way, we can at least handle the time zone in custom APIs. Actually, the docs (at https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/methods-auto/sessionsettings/sessionsettings-timezone-method) says that this work - but it does not (at least not when I was investigating this earlier)This Yammer thread handles the same request: https://www.yammer.com/dynamicsnavdev/threads/2322620781699072

Category: Development