Use ISO8601 as the DPN date-time format

[dazza-codes]

Exploring an alternative solution to #124 (cf. #125); may also fix #131

This solution focuses on using the ISO8601 datetime format. The last commit ensures it, but if the date format must or should be a parameter, the last commit can be dropped.

http://www.iso.org/iso/home/standards/iso8601.htm

[dazza-codes]

@Pcolar - does the DPN specification use ISO8601 for date formats? If not, what? Where is it defined? I assume it is defined somewhere, but have not yet found the details, e.g.

• https://github.com/dpn-admin/dpn-rest-spec/blob/master/definitions/timestamps.yml#L7
• https://github.com/dpn-admin/dpn-rest-spec/blob/master/parameters/after_created.yml#L6

This page does not explicitly identify ISO8601 as the DPN date-time standard:

• https://github.com/dpn-admin/dpn-rest-spec/blob/master/Standards.md#dpn-format-date-time

[Pcolar]

Date fields in DPN use ISO 8601. That was decided during the initial design and documented:
https://wiki.duraspace.org/display/DPN/Registry

last_fixity_date: ISO 8601
creation_date: ISO 8601
last_modified_date: ISO 8601

[dazza-codes]

@Pcolar - dpn-admin/dpn-rest-spec#13

[malakai97]

I think the confusion is arising because there are many iso8601 date formats.

[dazza-codes]

So long as the implementation can parse/return any of the iso8601 formats, it complies with the specification. Is there an additional requirement to use only a subset of the iso8601 formats? If so, should we elaborate on the reasons for that?

With regard to implementation details, it may help to look at the ruby API used, e.g.

• http://api.rubyonrails.org/classes/ActiveSupport/TimeWithZone.html

[dazza-codes]

In this PR, the #iso8601 method is used, which is an alias for #xmlschema, which is defined as:

# File activesupport/lib/active_support/time_with_zone.rb, line 134
    def xmlschema(fraction_digits = 0)
      fraction = if fraction_digits.to_i > 0
        (".%06i" % time.usec)[0, fraction_digits.to_i + 1]
      end

      "#{time.strftime("%Y-%m-%dT%H:%M:%S")}#{fraction}#{formatted_offset(true, 'Z')}"
    end

Copied from http://apidock.com/rails/ActiveSupport/TimeWithZone/xmlschema

[mikejritter]

Is there an additional requirement to use only a subset of the iso8601 formats?

iirc it originally came from wanting compatibility between all implementations, though even that I'm not clear on (or why it would be necessary since a good DateTime library should handle everything). Other than that using utc 0 as the time zone seems to be mostly for convenience reasons - like spot checking dates when testing and the like.

[dazza-codes]

This will need to be rebased and revised to adjust to the changes now merged from #125

[dazza-codes]

• rebased and revised.

[Pcolar]

Some parsing of the input data is not part of the active support library.
According to the Specifications, DPN will conform to ISO8601 standard. Go and JAVA libraries also support ISO8601.
One initializer in Develop uses a custom method for DateTime strings which strips milliseconds.
(https://github.com/dpn-admin/dpn-server/blob/develop/config/time_formats.rb#L9)

Unit tests are needed to demonstrate this use case.
Can we replicate issues with timestamp granularity?

[dazza-codes]

Although there were no problems in the specs, possibly because they are using the same method, this may not be correct. It might need to be modified to first ensure it is a UTC time, e.g.

[21] pry(BagAdapter)> Time.now.iso8601
=> "2016-10-31T13:46:26-07:00"
[22] pry(BagAdapter)> Time.now.utc.iso8601
=> "2016-10-31T20:46:34Z"

[dazza-codes]

If this PR were adopted, some commit squashing can be done to tidy it up. Leaving them as separate commits while this PR is open for review, in case there is discussion about using one or another alternative implementation.