ModDate in metadata does not match Last Modified Date from Item Page

1665
5
Jump to solution
09-14-2017 01:48 PM
PhilLarkin1
Regular Contributor

UPDATE: Answer per Atma Mani: use item.modified as described in REST API: ArcGIS REST API 

When accessing metadata from item.metadata, or downloading the metadata from item.download_metadata, the ModDate tag does not match the date shown on an Item's page. If these two dates are not intended to be the same, it would be nice if the Last Modified date was accessible in the metadata. 

For example, Item Page:
http://spokanecounty.maps.arcgis.com/home/item.html?id=9d299ad2fb664e90b6bfb136396653b2 

LastModifiedDate
XML Metadata for same item:

<Esri>
     <ArcGISstyle>ISO 19139 Metadata Implementation Specification GML3.2</ArcGISstyle>
     <CreaDate>2017-08-31</CreaDate>
     <CreaTime>13:35:59.71</CreaTime>
     <ModDate>2017-08-31</ModDate>
     <ModTime>13:36:03.39</ModTime>
     <ArcGISFormat>1.0</ArcGISFormat>
     <ArcGISProfile>ISO19139</ArcGISProfile>
     <PublishStatus>editor:esri.dijit.metadata.editor</PublishStatus>
</Esri>
<mdDateSt>2017-08-31</mdDateSt>
<mdFileID>9d299ad2fb664e90b6bfb136396653b2</mdFileID>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍
0 Kudos
1 Solution

Accepted Solutions
AtmaMani
Esri Contributor

Phil, I can reproduce the discrepancy. Calling the `modified` property of the `Item` object should get you the latest as shown below:

In [7]: datetime.fromtimestamp(my_item.modified/1000)
Out[7]: datetime.datetime(2017, 9, 19, 7, 0, 36)

In [8]: datetime.fromtimestamp(my_item.created/1000)
Out[8]: datetime.datetime(2017, 8, 31, 11, 38, 6)

Where as the date you get from XML calling the `metadata` on the Item object returns a different date.

One reason could be this. Behind the scenes, ArcGIS tries to sync the metadata fields (what you see on the item page which is same as what you get as properties on the Item object) with that of the metadata xml file. This sync could fail in cases where you have non-standard metadata fields defined in the XML, fields that ArcGIS is unaware of. We need to know how those were created to understand this better. I'd recommend you log a support ticket and explain your workflow.

On the other hand, if you only wanted to know the up to date modified date, you can use the code shown above.

View solution in original post

0 Kudos
5 Replies
PhilLarkin1
Regular Contributor

Can I get a confirmation of this bug from Group Admins? Should I log this as a support ticket? 

AMani-esristaffrsingh-esristaff

0 Kudos
AtmaMani
Esri Contributor

Phil, I can reproduce the discrepancy. Calling the `modified` property of the `Item` object should get you the latest as shown below:

In [7]: datetime.fromtimestamp(my_item.modified/1000)
Out[7]: datetime.datetime(2017, 9, 19, 7, 0, 36)

In [8]: datetime.fromtimestamp(my_item.created/1000)
Out[8]: datetime.datetime(2017, 8, 31, 11, 38, 6)

Where as the date you get from XML calling the `metadata` on the Item object returns a different date.

One reason could be this. Behind the scenes, ArcGIS tries to sync the metadata fields (what you see on the item page which is same as what you get as properties on the Item object) with that of the metadata xml file. This sync could fail in cases where you have non-standard metadata fields defined in the XML, fields that ArcGIS is unaware of. We need to know how those were created to understand this better. I'd recommend you log a support ticket and explain your workflow.

On the other hand, if you only wanted to know the up to date modified date, you can use the code shown above.

0 Kudos
PhilLarkin1
Regular Contributor

Thanks for your reply. 

It appears there are undocumented properties in the Python API. I don't see item.modified from this doc: arcgis.gis module — arcgis 1.2.1 documentation 

Should I assume that all properties exposed in the REST API are available in the Python API? 
Item: ArcGIS REST API 

0 Kudos
AtmaMani
Esri Contributor

In the API, we dynamically generate some properties from the JSON response we get back from the server. The key value pairs in this JSON might change slightly from scenario to scenario, hence, some properties might not exist for an object in the Python API (as this part is dynamic). Due to this, we do not explicitly document those properties in the API Ref Doc. However, we show how to use them in the guide and sample notebooks.


When in doubt, it is safe to check if the property exists like below:

In [12]: hasattr(your_item_object, 'metadata')
Out[12]: True

before calling it.

PhilLarkin1
Regular Contributor

Thanks again, Atma Mani-

I suppose a best practice when using the Python API is to always use hasattr().

The Python API would be much more dependable in a production environment if it had a tighter integration with the REST API. For example, all properties exposed for the Item Object at the REST API should be available and documented in the Python API. Keeping in sync with different versions of the REST spec is probably the big challenge for the dev team.

0 Kudos