Issue Description:

The customer has encountered an issue where the FSM Mobility app/Windows mobile sends the local time instead of UTC to the server for the location_as_of field (related to GPS fix). This issue is causing problems, particularly when the GPS fix is sent with the wrong time, as it prevents users from receiving task allocations for the rest of the day.

Example: A technician in Western Australia (UTC +8) sent a location_as_of value of 12:50:00, but the correct UTC time should have been 04:50:00. Due to this mismatch, PSO interprets the technician as unavailable for further task assignments.

In some records in the above screenshot, you may notice that the value of location_as_of (the first column without a column name) has a significant time difference of over 8 hours compared to created_dttm and modified_dttm.

Product Version: FSM 6 Update 26

Business Impact:
The incorrect timestamp blocks technicians from receiving additional tasks for the day, leading to operational inefficiencies.

Investigation Summary:

• The issue is intermittent and affects multiple Windows client technicians. The location_as_of field should always store the time in UTC, but occasionally, it stores the incorrect time.
• Logs from the Windows clients show recurring errors, though the FSM smart client appears to receive the correct timestamp for tasks.

  

   

• We noticed a correction in FSM 6 Update 28 that might be related to this issue, though it does not explicitly address location_as_of.
• There are no customizations or configurations related to this screen and customer confirmed it.
• Additionally, we noted that an additional correction(which is not relevant to any specific case) which might be related to this issue is included in FSM 6 Update 28 corrections, R&D’s initial response was that the fix for work_dt in FSM 6 Update 28(which shown in the below screenshot) is unlikely to resolve this issue, as it specifically focuses on that field alone.

Request for Community: Could anyone please verify if the correction in FSM 6 Update 28 (or any related fix) could resolve this issue? Alternatively, has anyone encountered a similar problem, and if so, how was it addressed? The customer is open to updating to the latest version if R&D can confirm this will fix the problem.

Thanks in advance for your help!