web
You’re offline. This is a read only version of the page.
close
Skip to main content
Community site session details

Community site session details

Session Id :
Microsoft Dynamics AX (Archived)

Best solution for time differences between session time and AOS time?

(0) ShareShare
ReportReport
Posted on by 235

We have several issues with how AX 2009 handles date and time stamping transactions due to the fact the time difference between where our AX application server is located and one goup of users.

The time difference is 9 hours.  During the first couple hours of the users business day the issue we're seeing is the following:

1. they create a sales order which is stamped using the session date and time for that user.

2. If they advance the order to the packing slip stage, we have noticed that the packing slip is using the AOS date and time which in this case is yesterday.

3. in the end it looks like the order was shipped before the order was actually created.

4. This same issues with date and time occurs during our period close process where transactions are not permitted for the first few hours of the users business day because posting date used is the AOS date which is still in the previous period.

As we add addiitional user groups, this issue will only become more apparent.  Are there ways to manage this other than telling the business sorry, you can't run transaction for the first few hours of your business day or having them manually change the dates for two hours every day?

 

 

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    I would suggest configuring your AX app server to match the date/time of your users.

    That would be the best option I believe.  Other then that, you could modify AX to set date and times of your orders to that of your app server but that would be a heavy modification and most likely not recommended.  Look into UTCDateTime functionality.  Every date/time that goes into fields is converted to the users preferred time zones.  So in actuality, the two matchup but you don't see that in the user interface.  Read the below link for some good info:

    community.dynamics.com/.../conversion-from-utcdatetime-to-date-or-time.aspx

    Also, there is perhaps a way to turn off the conversion but it would still leave a problem where you would see an order created now that looks like it was created 9 hours ago.

    Hope this helps somewhat.

    Kind regards.

  • M Morris Profile Picture
    235 on at
    Re: Best solution for time differences between session time and AOS time?

    Thanks, this is actually the solution we were considering.  But we were curious if there might be another possibility before adopting this option.

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    We are experiencing the same issue (currently working on a potential solution, without needing to rewrite large amounts of base code).  So far I have a solution for the systemDateGet() call, still working on solving the timeNow() call issue.   When I have a working solution that does not required large amounts of base code rewrites, I will let you know.    

    Kent, setting the AOS time/date settings for one group of users will not work for international businesses with multiple offices using 1 AOS as there will always be an issue with the systemDateGet() and timeNow() calls.  If these were properly based on UTC time then there would be no issue (HINT: Microsoft a solution to the problem that needs to be fixed at the kernel level without major base code rewrites).  

  • M Morris Profile Picture
    235 on at
    Re: Best solution for time differences between session time and AOS time?

    Barry,

    Thanks for ther reply.  I would definitely be interested in ways to address this programmatically and agree...Microsoft needs to address this as it appears that AX 2012 has the same issue.

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    Barry,

    I agree.  I bet MS would recommend using multiple AOS's however.  I would like to point out that if you are writting custom code and using systemDateGet() or timeNow() calls, you should be using UTCDateTimeUtil instead (in your scenario)

    i.e.
    public static void testDateTimeConversion()
    {
        utcDateTime dateTime;
        date dateInUserTimeZone;
        TimeOfDay timeInUserTimeZone;

        dateTime = DateTimeUtil::utcNow();

        dateInUserTimeZone = DateTimeUtil::date(DateTimeUtil::applyTimeZoneOffset(dateTime, DateTimeUtil::getUserPreferredTimeZone()));
        timeInUserTimeZone = DateTimeUtil::time(DateTimeUtil::applyTimeZoneOffset(dateTime, DateTimeUtil::getUserPreferredTimeZone()));

        dateTime = DateTimeUtil::newDateTime(dateInUserTimeZone, timeInUserTimeZone, DateTimeUtil::getUserPreferredTimeZone());
    }

    https://community.dynamics.com/product/ax/axtechnical/b/axdaily/archive/2010/02/08/conversion-from-utcdatetime-to-date-or-time.aspx

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    Kent,

    Ideally I agree.  There are other factors to take into account.  When I have finished testing, I will post the changes I've had to make.  (This site lost the answer I just wrote with an outline of the changes I've already made).

    Hoping to have a complete solution by early next week.

    Barry.

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    It seems the site is unable to handle the solution in one reply, so I will break it into parts.

    Here is a quick update.  Let me know if there are any issues or situations that need to be addressed.


    USING LOCAL TIME

    Introduction:
    The following is a work in progress update, as the solution has yet to be fully tested in all situations.

    Problem:
    If the user has a different time zone to the AOS, the timeNow() and systemDateGet() functions are returning the AOS details when the local date time is required. 

    Clarifiers:
    When the local date time is changed within Axapta, the systemDateGet() function will return the local date, however the timeNow() function still returns the AOS time.

    Coding changes:
    A number of coding changes have been made to handle a number of different situations.  Comments will be added where an explanation may be required.

    The brackets were changed to [ and ] to allow this to be posted.


    CLASS:GLOBAL

    One requirement I was given was to allow the system to handle multiple sites within a comany that may have different time zones.  Presently this functionality is not required.

    static server void setSessionDateTime(
     inventSiteId  inventSiteId = '',
     utcDateTime  reference = dateTimeUtil::utcNow())
    [
        str                             sql;
        sqlStatementExecutePermission   perm;
        connection                      conn        = new UserConnection();
        timeZone                        timeZone;
        int                             ret;
        ;

        if (inventSiteId)
        [
            timeZone = inventSite::find(inventSiteId).Timezone;
        ]
        else
        [
            timeZone = dateTimeUtil::getCompanyTimeZone();
        ]

     //This is to get around the kernel validation of changing timezones when the user has more than one session open.

        sql     = strfmt("Update userInfo set preferredTimeZone = %1 where userInfo.id = '%2'", enum2int(timeZone), curUserId());
        perm    = new SQLStatementExecutePermission(sql);
        perm.assert();

        ret = conn.createStatement().executeUpdate(sql);

        dateTimeUtil::setUserPreferredTimeZone(timeZone);
        dateTimeUtil::setSystemDateTime(reference);

        CodeAccessPermission::revertAssert();
    ]

    static int localTime()
    [
        utcDateTime tmp;
        ;
        setSessionDateTime();

        tmp = dateTimeUtil::applyTimeZoneOffset( dateTimeUtil::utcNow(), dateTimeUtil::getCompanyTimeZone());
        return dateTimeUtil::time(tmp);
    ]

    The following method was implemented as a cross check to ensure that systemDateGet() returns the expected value.

    static date localDate()
    [
        utcDateTime tmp;
        ;
        setSessionDateTime();

        tmp = dateTimeUtil::applyTimeZoneOffset( dateTimeUtil::utcNow(), dateTimeUtil::getCompanyTimeZone());
        return dateTimeUtil::date(tmp);
    ]


    CLASS:APPLICATION

    Modify the method 'setDefaultCompany'.  Add the line 'setSessionDateTime();' directly after the super call.  This is to allow the time to change when the user changes company (another requirement I was given).


    CLASS:INFO

    So that the system uses the correct date/time from the start of the session.

    void startupPost()
    [
        ;
        setSessionDateTime();
    ]

    Modify the method 'canViewAlertInbox()' adding the line 'setSessionDateTime();' as the first line.  This is to handle if the user has multiple forms open for differnet companies.

     

    Locationisation dependant changes:

    Depending on your service pack and locationisations, you will need to change a function of objects to use the localTime() function, replacing timeNow().  IMPORTANT NOTE: Do not change the class BatchRun to use the new localTime function as this will stop it working correctly.

    In our system there were around 260 instances that could be changed.  If you do not use all modules and locationisations the actual number of lines you need to change will be less.

     

    Final note:

    There are a number of today() calls in the code.  I have not yet gone through each line to ensure it is coded correctly, i.e. using today() instead of systemDateGet(). 


    Known issues:

    I have come across a situation where the timezone change function did not work competely as expected.  This was when one session was doing a database synchronisation and another session was opened in a different company.  As normal users will never be able to do this, I have not spent much time on its solution at this stage.  It is something I do intend to resolve.

     

     

     

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    Quick update.  We have put the solution into our live environment and I am waiting on feedback for any issues that may occur.

    There were a number of objects that needed to be changed that referenced: timeNow() and Today().  It appears that the Today() function has been incorrectly used in places.

  • Community Member Profile Picture
    on at
    Re: Best solution for time differences between session time and AOS time?

    A problem raised with the solution is that it does not work correctly in batch mode.  Two workaround:

    1. Move the setSession code to a new class and set the called on setting to server and change the code as follows

    static server void setSessionDateTime(utcDateTime reference = dateTimeUtil::utcNow())

    [

       str                             sql;

       sqlStatementExecutePermission   perm;

       connection                      conn        = new UserConnection();

       timeZone                        timeZone;

       int                             ret;

       session                         session = new Session();

       ;

       if (session.clientKind() != clientType::WorkerThread)

       [

           timeZone = dateTimeUtil::getCompanyTimeZone();

           sql     = strfmt("Update userInfo set preferredTimeZone = %1 where userInfo.id = '%2'", enum2int(timeZone), curUserId());

           perm    = new SQLStatementExecutePermission(sql);

           perm.assert();

           ret = conn.createStatement().executeUpdate(sql);

           if (timeZone != dateTimeUtil::getUserPreferredTimeZone())

           [

               dateTimeUtil::setUserPreferredTimeZone(timeZone, true);

               dateTimeUtil::setSystemDateTime(reference);

           ]

           CodeAccessPermission::revertAssert();

       ]

    ]

    Unfortunately this will mean use of incorrect dates.

    2. Rewrite system code and replace systemDateGet() with localDate().

    This is the option I am implementing.

  • Community Member Profile Picture
    on at
    RE: Best solution for time differences between session time and AOS time?

    Kent,

    You mention that MS would recommend multiple AOS to address the time zone issue.

    Since the use of Virtual Servers ease the hardware cost component, are there other concerns for the option of setting AOS1 and AOS2 as EST and AOS3 and AOS4 as PST and then directing the users to the AOS that matches their localization?  If all the AOS are pointing to the same SQL, and the Legal Entity has the Time Zone set as EST.

    The issue is the west coast Inventory movement transactions that occur after 9:00pm PST / Midnight EST posting to the next day.

    Thanks for your (or anyone else) reply on this configuration.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Responsible AI policies

As AI tools become more common, we’re introducing a Responsible AI Use…

Pallavi Phade – Community Spotlight

We are honored to recognize Pallavi Phade as our Community Spotlight honoree for…

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

#1
Martin Tocauer Profile Picture

Martin Tocauer 4

#2
AlissonGodoy Profile Picture

AlissonGodoy 2

#2
Community Member Profile Picture

Community Member 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans