Milliseconds are dropped from dateTime

[tcmitchell]

When an SBOL file contains a dateTime with zero milliseconds the milliseconds are dropped when that file is written out. For an example, download https://synbiohub.org/public/igem/igem2sbol/1:

curl -o igem2sbol.xml https://synbiohub.org/public/igem/igem2sbol/1/sbol

This results in an sbol file with the following dateTime entry (reformatted for easier viewing):

<prov:endedAtTime rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
  2017-03-06T15:00:00.000Z
</prov:endedAtTime>

This dateTime has zero milliseconds. When pySBOL2 reads then writes this file it results in the following dateTime (again, reformatted for easier viewing):

<prov:endedAtTime rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
  2017-03-06T15:00:00+00:00
</prov:endedAtTime>

@cjmyers said in a comment on another issue:

We expect that if a library reads and writes an SBOL file without making any changes that the written file will compare with no differences to the original.

If taken literally, this means we would have to store the textual representation and use that unless changes are made to the dateTime property. If that's more of a semantic "no differences" then we should be ok with this.

Open questions:

• What about the time zone offset? Do we have to use "Z" because the dateTime originally had a "Z"? Or is it ok that it is converted to "+00:00"? "Z" would be the literal "no differences", and "+00:00" would be ok with a semantic "no differences".
• By default Python wants to use microseconds (six digits), so we round trip 123 milliseconds (as in "2006-01-02T15:04:05.123Z") as 123000 (as in "2006-01-02T15:04:05.123000+00:00"). The literal "no differences" would require the former, and the semantic "no differences" should allow the latter.

[bbartley]

If taken literally, this means we would have to store the textual representation and use that unless changes are made to the dateTime property. If that's more of a semantic "no differences" then we should be ok with this.

Semantic equivalence should be sufficient I would think. The lexical discrepancy seems to be occurring because of the default representation of the underlying datetime utilities that pySBOL2 and libSBOLj rely on. But despite the lexical differences they should still evaluate as logically equal, assuming that each library preserves the data type upon file I/O. For example:

>>> d1 = dateutil.parser.parse('2017-03-06T15:00:00.000Z')
>>> d2 = dateutil.parser.parse('2017-03-06T15:00:00+00:00')
>>> d1 == d2
True