Select to view content in your preferred language

Feature Service does not use IANA standard for Time Zones pre 2007

357
2
10-08-2024 01:37 PM
Status: Open
SeanLyons
Regular Contributor

During our Migration to Pro we were trying to standardize all our date fields to be in UTC to match the editor tracking fields, that are mandatory UTC, but have date entry for all other fields using a time zone preference that is not UTC. Time zone preference is supported in a feature service. We were trying to use best practices to have a consistent time offset between all date fields. It was found that any date pre 2007 is not obeying the IANA logic for time zone conversion which is causing erroneous dates.

This example is all going to be shown as what the UI is seeing and not what the database is storing. Take for example Mar 9, 2006, in desktop it had no time stamp, in Pro that has become Mar 9, 2006 12:00am. When you view that in the service it is becoming Mar 8, 2006 11 am since the background time zone conversion is not obeying the logic for proper time zone conversion. This same bug is also prevalent in the Time Zone Conversion GP tool which has the same issue.

We have lots of legal dates that need to be correctly shown that are pre 2006 that we need to have faith are going to be handled correctly.

2 Comments
EmilyGeo

Hi @SeanLyons

I'm sorry you are experiencing this. This can be an issue when working with Date fields in ArcGIS Online. The Date field assigns a time value when there is none, and makes adjustments to how the value is displayed on the fly. Luckily there are some ways to manage that.

If the dates don't contain a time value, one possible workaround is to use the Date Only field. This field stores only the date, with no associated time. In a Date Only field, the value remains as-is whereas, as you have seen, the value in the Date field can be adjusted based on device time. 

For more on managing date and time data, please see these articles:

Hope that helps! 

SeanLyons

Hey @EmilyGeo,

Unfortunately date only fields won't work, as we need the time stamp as well as the date stamp and it needs to be in a single field with a proper time zone offset not split fields to ensure data integrity. There is already the issue of the fact that postgres date time offset fields are not a supported field(https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/manage-postgresql/data-types-postgre...) but that is a different team. The date time offset not being handled correctly should be something that is fixable within the software as all time zone offset aware fields should be using the correct time zone conversion logic consistently for all dates that are covered by the IANA logic. The same thing for the GP tool for time zone conversion which I think is already a logged bug, all time zone zone conversion should be consistent for all components whether it is GP tool or part of the service.