Set up ArcPad to use UTC time instead of local database time

[JosephMootz1]

I have an ArcPad 10.2.2 app that synchronizes with an ArcGIS Server using a feature service. It works fine without Editor tracking enabled and with Downloads Suppressed. I have set it up to use Editor Tracking, but there is a discrepancy in how ArcPad handles the Edit Date field. This field is in UTC time on the ArcGIS Server. During the synch process this field gets converted to local database time in the ArcPad .axf file. Therefore, every record is downloaded for every synch process because the time zones are different between the ArCGIS Server REST Service and the ArcPad .axf file. I understand the REST service requires the use of UTC time and that cannot be changed. I have verified that by changing my local computer time to the UTC time zone the synch process works as it should only downloading records that have changed.

I notice that the same conversion happens going from ArcPad to the ArcGIS server with other date fields. I have date fields in ArcPad that when synched to the ArCGIS server are different by 7 hours from what they are in the .axf file.

Is there a way to set up ArcPad to use UTC time instead of local database time?

We do not use a GPS unit with this application.

[IngridHogle]

We had the opposite problem, which was that our local time was getting converted to UTC time during sync, and we reported this as an ArcPad 10.2.1 bug last year. Esri fixed this in ArcPad 10.2.2 by way of changes to ArcPad's sync.js file, but it sounds like the fix, which helps us, is not a good thing for your application. You could downgrade to ArcPad 10.2.1 to get the behavior you are requesting.

[JosephMootz1]

Thank you for this response it was very helpful in trying to understand what is going on.

I found the place in the synch.js code where the timezone offset is subtracted from the date during the download process. I removed the subtraction of the timezone from the line below and the dates seem to be kept in synch.

     // Convert from milliseconds (epoch 01-Jan-1970 UTC) to days (epoch 30-Dec-1899 Localtime).

     fieldValue = 25569.0 + (fieldValue / 1000.0 / 60.0 - (new Date()).getTimezoneOffset()) / 24.0 / 60.0;

The timezone offset is also subtracted during the upload process, but it does not effect synchronization of the dates.

       // Convert from VARIANT time to UNIX time.

       fieldValue = fieldValue - (new Date().getTimezoneOffset()) * 60.0 * 1000.0;

It appears to me that the ArcPad date and time is stored as local database time (days (epoch 30-Dec-1899 Localtime) and the ArcGIS server date and time are stored as UTC date and time (milliseconds (epoch 01-Jan-1970 UTC)). During the upload portion of the synch process the ArcPad date and time is converted to the ArcGIS Server format by subtracting the timezone offset. So if I have a time of 15:00 in ArcPad it still appears as 15:00 when uploaded to ArcGIS server.

If I try to synch again, the timezone is subtracted from the ArcGIS Server time during the download process. On the west coast this results in 7 hours being added to the time making the time now 22:00.

On ArcGIS Server the EditDate is in UTC Time, so there is no need to subtract the time zone offset when downloading to ArcPad. With the original code, 7 hours were subtracted from the EditDate, so that a feature edited at 22:00 on ArcGIS Server gets downloaded with an EditDate time of 15:00. So when the synch process is tried again, the EditDate on ArcPad is always 7 hours earlier than the EditDate on ArcGIS server so the feature always appears out of synch.

I am still not sure if I have this all right. I have not had a chance to double-check all the calculations but I think they are right. Basically, if a date and time are recorded as local time on ArcPad I would like the same value for date and time to appear in ArcGIS Server, 15:00 on ArcPad = 15:00 on ArcGIS Server. If ArcGIS server records a date as UTC, it should still have the same value when downloaded to ArcPad otherwise there is no way to tell which features need to be synchronized.

The solution for me seems to be to remove the subtraction of the Timezone offset on the Download.