Uploaded image for project: 'DSpace'
  1. DSpace
  2. DS-2387

Items with no embargo request cause "Embargo lift date must be in the future, but this is in the past"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Volunteer Needed (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2, 5.5
    • Fix Version/s: None
    • Component/s: XMLUI
    • Labels:
    • Environment:
      Linux RedHat, Tomcat 7, PostgreSQL 9.3
    • Attachments:
      0
    • Comments:
      4
    • Documentation Status:
      Needed

      Description

      Upon approving the majority - strange enough not all cases - of the submitted items whose authors do not ask for embargo period, the following error pops up.

      java.lang.IllegalArgumentException: Embargo lift date must be in the future, but this is in the past: 2014-12-30T12:15:59Z

      Also, it is noticeable that the time printed in the error message is always the GMT time not the local time of the server.

      I checked the server's date and it is the local time as shown below:

      1. date
        Tue Dec 30 14:59:40 EET 2014

      Also, I checked the timezone settings in the postgresql.conf and it is set as follows:
      timezone = 'EET'

      Finally, I traced the code in EmbargoManager.java (line 158) as the Java Stacktrace states the following:
      java.lang.IllegalArgumentException: Embargo lift date must be in the future, but this is in the past: 2014-12-30T12:15:59Z
      at org.dspace.embargo.EmbargoManager.getEmbargoTermsAsDate(EmbargoManager.java:158)
      at org.dspace.embargo.DefaultEmbargoSetter.setEmbargo(DefaultEmbargoSetter.java:81)
      at org.dspace.embargo.EmbargoManager.setEmbargo(EmbargoManager.java:102)

      The mentioned line in embargoManager.java is
      // sanity check: do not allow an embargo lift date in the past.
      if (liftDate.before(new Date()))

      { throw new IllegalArgumentException( "Embargo lift date must be in the future, but this is in the past:" + result.toString()); }

      The problem as I can analyze it is as follows:
      Date liftDate = result.toDate(); produces DCDate date and time i.e. UTC time
      while new Date() function produces local time date and time

      when the authors request their item becomes available, the liftdate is set as per DayTableEmbargoSetter.java as follows:

      long lift = System.currentTimeMillis() +
      (Long.parseLong(days) * 24 * 60 * 60 * 1000);
      return new DCDate(new Date(lift));

      Thus it is set in terms of DCDate i.e. UTC time. Accordingly, it is set to the current time in UTC timezone.

      When the sanity check in EmbargoManager.java checks whether liftDate is before new Date(), it compares the UTC current time (in liftdate) to that of the current local timezone (in new Date()) causing error to the cities whose timezone is East to GMT.

      I suggest to change the linecode 158 in embargoManager.java to be

      if (liftDate.before(new DCDate(new Date())))

      OR to change it to this code:

      // sanity check: do not allow an embargo lift date in the past.
      String format = "yyyy/MM/dd HH:mm:ss";
      SimpleDateFormat sdf = new SimpleDateFormat(format);

      sdf.setTimeZone(TimeZone.getTimeZone("UTC"));
      Date gmtTime1 = new Date(sdf.format(new Date()));

      if (liftDate.before(gmtTime1) )

      Please advise. Thank you

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              soumaia Soumaia Ahmed Al Ayyat
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: