Task #7645
MNDeployment #3557: LTER Network
LTER object(s) not synchronizing - bad dateSysMetadataModified?
0%
Description
I stumbled across an object from LTER that isn't getting included in list objects. (doi:10.6073/AA/knb-lter-bes.417.47)
I believe it is because the dateSysMetdataModified uses the Z format for time zone.
In the MN copy, notice the Z in the modified date field:
2015-03-06T07:09:13.931577
2016-01-13T13:01:44.579484Z
A listObjects call fails to retrieve this object. Calling https://gmn.lternet.edu/mn/v1/object?fromDate=2016-01-13T12:00:00.000&toDate=2016-01-13T14:00:00.000
returns:
Also, this object is an old object that looks like it has been reloaded, since the dateUploaded is different between LTER and the CN:
https://cn.dataone.org/cn/v2/meta/doi:10.6073/AA/knb-lter-bes.417.47
https://gmn.lternet.edu/mn/v1/meta/doi:10.6073/AA/knb-lter-bes.417.47
Maybe there are others just like it.
Related issues
History
#1 Updated by Rob Nahf almost 9 years ago
discovered that a listObjects call restricted to the time window around the CN's listing of the modification date (2012-06-26T10:41:36.229+00:00) does return the item:
doi:10.6073/AA/knb-lter-bes.417.47
eml://ecoinformatics.org/eml-2.0.1
84a5a7f446bed53b2a5f9090dfc2e7d9
2012-06-26T10:41:36.229
11435
/ns1:objectList
Looking at the underlying GMN database tables for LTER, Mark noticed a discrepancy between what the database held (the 2012 date), and the one in the serialized SystemMetadata object returned by GMN (the 2016 date).
#2 Updated by Mark Servilla over 8 years ago
- Related to Bug #7651: GMN returns two different dateSysMetadataModified dateTime stamps for same object added
#3 Updated by Mark Servilla over 8 years ago
- Status changed from New to Rejected
- translation missing: en.field_remaining_hours set to 0.0
This issue is not related to the dateTime format: see #7651.
