Different Time Zones reflected in different fields

Hi

I can see that this is the 23R2 version and not 24R1 version, but please update us on it.

In 23R2 we implemented the UTC version of time zone

In 24R1 we implemented the known server time zone.

In 24R2 it is planned to include the site time zone. 

In neither 23R2 or 24R1 MWO has done any changes to the time zone in their enitites, except for maybe some few shared entities with other product groups. 

The app client framework has however support for time zone as the app Mobile Maintenance for aviation did do the implementation for UTC time zone as well as for known server time zone. 

The backend (server) is also handling the time zone, in 23R2 the UTC time zone and in 24R1, the known server time zone, especially to support the data into the correct time zone to the app. I am prerry sure we did not do any changes to the presentation of the time zone in the mobile framework backend at all and should use the time zone that is set on the server, regardless if it was UTC or known time zone. 

I have asked our architect to have a look at this community post as well, as he is bit more into what we actually implemented on the Mobile framework.

Regards

Johan

Hi, This environment is in 23R2 and we will upgrade to 24R1 soon. I have also attached the device logs herewith

Hi

The Mobile Out Queue and Push Queue uses database time without any conversions. However, what you observed doesn't seem correct. How do you know those out messages are linked to the push queue record?

Hi,

You are correct. The times you see in the mobile out messages, which are in UTC, are written by the middle tier, while other messages in the same table are in the database time zone and are written by the PLSQL logic. This inconsistency in display values won't affect the mobile data sync functionality but might cause confusion when troubleshooting sync issues by examining the out messages by created datetime. We have investigated thus internally and found that the Middle tier always  has the UTC TZ. So we will need a fix to align those timestamp values. 

Thanks

Kapila

Hi @kapilk,

we have reported CS0236512 for further investigations on this