There are inconsistencies in how DateTimes are stored in the ArcGIS Platform, especially in relation to Daylight Savings Time. These inconsistencies cause issues when analysing the data or using it in other systems.
I believe the below to be correct but cannot be responsible for any errors. Examples below are from New Zealand.
WebApp – Smart Editor
In the Smart Editor, the origin datetime used by the Date Selector is Midnight, and it gets converted to UTC time for storage.
- If the date selected is during the summer, the Date will be saved as a DateTime in UTC (NZST-13:00, so 12 January gets stored as 2021-01-11 11:00)
- If the date selected is during the winter, the Date will be saved as a DateTime in UTC (NZST-12:00, so 2 July gets stored as 2020-07-01 12:00)
Summary: In ArcGIS Pro, regardless of the time of year, the DateTime shown in the attribute table will be the same, it will be relative to the timezone offset at the time of year of the date in question.
Survey123
Survey123, on the other hand writes Dates as zoned DateTime objects with an origin of Midday.
Upon capture, the device says “This date is 2020-05-05 12:00:00+13:00” and the server converts this to UTC 2020-05-04 23:00:00+00:00 for storage
But in winter, if you go into the attribute table, you will see the same date display as 2020-05-05 00:00:00+00:00
Summary: In ArcGIS Pro, the DateTime shown in the attribute table is the date relative to your current timezone (-13 if you are currently in summer, -12 if you are currently in winter)
This difference between products is frustrating. Please standardise the approach for DateTime storage.
