OAI-PMH with datestamp updated daily on OJS 3.1.1.2

Software Support
1

Hi guys!

We found a problem on OJS 3.1.1.2 in different installations, so it seems to be a bug on that version. The datestamp of each recent issue is updated daily. As an example, a issue published in july, and with any changes made after, the datestamp of the records on OAI-PMH is updated daily, when this behavior should only exist if the item has been updated with any new information.

We found this situation because we manage an OAI-PMH harvester and we have daily reports of what is new and found this behavior on the recent installations (3.1.1.2).

Example: https://www.actaurologicaportuguesa.com/index.php/aup/oai?verb=ListRecords&metadataPrefix=oai_dc

We can see this by using the journal OAI or the “root” OAI of the installation.

There is any change on the code to produce this daily update?

Regards,

José Carvalho

2

You are probably talking about the field that shows 2018-08-31T01:36:13Z for article/3 at the moment?

I know that there has been changes in the OAI code. I can take a look, because I have been getting reports from our national library that they are getting a lot of reports for changed articles from our OAI-PMH. Could be the same issue.

I will just wait a while now and see what happens to that timestamp…

3

Yes @ajnyga, that’s it. Now the date is : Datestamp 2018-09-03T01:37:16Z

This only happens to issues published on the last OJS version, and not to all items of the journals. I have this issue in several journals with the last OJS version (3.1.1.2).

Regards,

José Carvalho

4

Hello,

We are on OJS 3.1.0.1 and seems to have similar issues with timestamp. Have you had any solution?

Regards,
Yanan

5

Hi
We have the same problem on OJS 3.1.1.4 . The “earliest Datestamp” is allways “today”. See Open Journal Systems .
That generates problems regarding discovery imports in Primo for example.
Regards
jan

1 Like
6

Hi @trace,

I’d recommend upgrading; I can’t reproduce that problem on a recent release, and the relevant code has undergone significant changes since version 3.1.1-4.

Regards,
Alec Smecher
Public Knowledge Project Team

7

Hi Alec
We’re on 3.1.2 now. The problem persists. We need the API to feed remote IS like the new swisswide catalogue “swisscovery” (ExLibris Primo). Automated scheduling is not possible like this. May you have some clues how we should proceed? Kind Regards.
Jan

8

Hi @trace,

3.1.2 is still really old – the latest 3.2.x and the newly-released 3.3.0 are what we’re actively maintaining at the moment. Any chance you could try with a newer release?

Thanks,
Alec Smecher
Public Knowledge Project Team

9

Hm, in my opinion the bug is critical. The protocol should run on every release. But maybe we’re the only ones facing it. I don’t know. Ok, I hope the next update will fix it.

10

Hi @trace,

I haven’t seen the behaviour you describe, and the first step in figuring out its cause is to replicate it on a recent release. I wonder whether one of the plugins related the OAI interface (e.g. Driver) might be related.

Regards,
Alec Smecher
Public Knowledge Project Team

11

Hi Alec

Thanks.
I’ve discovered that the error only occures when retrieving the instance as a whole Open Journal Systems . Seperate journals are working like Open Journal Systems .

We haven’t the Driver plugin enabled.

Regards
Jan

12

Hi @trace,

I’m afraid I still can’t see that behaviour on a new release. If you’re able to replicate it on a 3.2.x or 3.3.x installation, and can provide a bit of detail on how, I can look into it further.

Regards,
Alec Smecher
Public Knowledge Project Team

13

Thanks Alec. Yes, I see we have to update the version. I’m not sure if it is a problem of OJS anyway. Maybe it’s some setting on our server. But we have no clue at the moment. I will get back to you if the problem persits after the update.
Kind Regards
jan

1 Like
14

Hi @asmecher

I can confirm this bug in 3.2.1-4 for any format (DC, JATS…).

Wired part is somethimes datestamp is fine:

But others don’t:

As said, the issue is not just with DC. I can see it with JATS:

Article 1 (JATS) - OJS 3.2: http://ada.uab.cat:8121/enrahonar/oai/?verb=GetRecord&metadataPrefix=jats&identifier=oai:ojs.redi.enrahonar:article/1

Last week some fellows from the ojs-es.network reported same issue in their ojss.

Could it be related with a personalization/localization of date formats in config.inc.php?

Let me know if you want me to open a gitHub issue or if you need a testing journal.

15

Hi @marc and @trace,

Have both of you altered the date formats in config.inc.php from the defaults? If so, that would be a place to start investigating.

Regards,
Alec Smecher
Public Knowledge Project Team

16

Yes. This is what I was trying to say with: :blush:

In all my config.inc.php my dates are always in our own locale:

date_format_trunc = "%d-%m"
date_format_short = "%d-%m-%Y"
date_format_long = "%B %e, %Y"
datetime_format_short = "%d-%m-%Y %I:%M %p"
datetime_format_long = "%B %e, %Y - %I:%M %p"
time_format = "%I:%M %p"

On Monday I can do an upgrade with a clean config.inc.php, but the original journal dates will be in EU format so I don’t if this would help. :sweat_smile:

The issue was reported by a fellow when he was harvesting RACO (the big OJS with more than 500 journals):

http://www.raco.cat/index.php/index/oai/?verb=ListIdentifiers&set=enrahonar&metadataPrefix=oai_dc

May be @ajnyga also changed date formats and can confirm the issue is related with this?

17

Hi all,

I was able to find an issue that could cause current dates to always be shown for the earliest OAI datestamp in OJS/OMP/OPS 3.3.0-2 and 3.3.0-3 – this will be fixed in 3.3.0-4, due for release in the next week or two. But I haven’t been able to determine the cause in older releases. @marc, looking over the code I don’t think a change of date formats would explain this (the OAI code uses its own date formatting code, distinct from the front-end formatter), but if you are able to make a connection please let me know.

Regards,
Alec Smecher
Public Knowledge Project Team

18

Hi Alec and Marc

Yes, that was the case in our instance. I’ve changed to local time formats in the config file probably more than a year ago. But I did a reset to default time settings some weeks ago after assuming that could be a problem. Unfortunately without any effect unitl now.
Regards
Jan

19

Hi @asmecher and @marc ,

from RACO instance commented by Marc we have the same problem when export some articles by OAI, datestamp showed is the current date you are querying oai.

We have been investigating because we found that it works fine for some journals and for other the datestamp for record shows current date.

I think the problem is related to migrated data from ojs 2 to ojs 3 (our version is 3.1.4) because the issue last_modified value for some issues that were created on ojs 2 is NULL, for issues created from ojs3 the value is the same as date_publish (or a new date if it was modified after publication). There are no NULL values for new issues created from ojs 3 all NULL values all were created using ojs2 version before we updated.

To test it I tried to change from database NULL values for a date for a journal that show current date as DateStamp and seems it works. No current date is showed for this records, the date showed is the date I’ve changed updating the database.

It have sense foru you? Can it be the problem?

If it is the problem for current installations can be “easily” solved updating last_modified NULL values for date_publish value for affected issues.

Natalia

1 Like
20

It makes a lot of sense Natalia… and the workaround is perfect.

I mean, I can’t imagine situations where null could be better than the published_date so I think we can safely overwrite it with a single UPDATE query.

@asmecher, do you accept PRs to include Natalia’s proposal to the upgrade script for 3.2 and 3.3 branches?

I will confirm this tomorrow in my journals, but I love to hear Alec’s comments

Thanks you both your work,
m.