Project

General

Profile

Task #7645

MNDeployment #3557: LTER Network

LTER object(s) not synchronizing - bad dateSysMetadataModified?

Added by Rob Nahf about 8 years ago. Updated about 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
Start date:
2016-02-17
Due date:
% Done:

0%

Story Points:
Sprint:

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

Related to Python GMN - Bug #7651: GMN returns two different dateSysMetadataModified dateTime stamps for same object New 2016-02-22

History

#1 Updated by Rob Nahf about 8 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:

https://gmn.lternet.edu/mn/v1/object?fromDate=2012-06-26T10:40:00.000+00:00&toDate=2012-06-26T10:45:00.000+00:00:

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 about 8 years ago

  • Related to Bug #7651: GMN returns two different dateSysMetadataModified dateTime stamps for same object added

#3 Updated by Mark Servilla about 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)