[Dachs-support] [Dachs-users] DaCHS Release 0.9.8

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Dec 9 11:15:44 CET 2016


Hi Yannick,

On Thu, Dec 08, 2016 at 04:14:22PM +0100, Yannick Roehlly wrote:
> Le jeudi 8 décembre 2016, 14:18:33 CET Markus Demleitner a écrit :
> > Before upgrading, please make sure all your RDs are in order (run 
> > gavo val ALL), as broken RDs may disturb upgrade procedures.
> 
> I took the opportunity to correct some errors spotted by "gavo validate". In 
> particular, I was used to indicate the creation date with a timezone like 
> this: "2015-12-09T13:45:28+0100" but validate was complaining so I had to 
> change to "2015-12-09T13:45:28+01:00" (note the ':' in the timezone) and 
> validate was not complaining anymore.

Ah.  Turns out my belief that the VOResource schema forces created
and updated to be UTC (i.e., all that's allowed is a trailing Z) is
wrong; it's a normal xs:dateTime, which is why the registry record
validation succeeds.

Going down the rabbit hole, I notice that the bold declaration in
VOResource,

  All VOResource elements and attributes that contain dates must be
  interpreted as UTC dates and must be encoded in compliance with ISO8601

isn't really backed up by the schema anywhere except possibly in
vr:Date).  Oh, shucks.  I'll have to think about how to clean this
one up for VOResource 1.1.

Anyway, DaCHS wants all datetimes in the form

2015-12-09T13:45:28Z

> But visiting a ressource page with DaCHS 0.9.8 was displaying this error 
> message:
> 
>  A(n) ValueError exception occurred. The accompanying message is: 'Bad ISO 
>  datetime literal: 2015-12-09T13:45:28+01:00'
> 
> Reverting back to the old format did not correct the problem so I left only 
> the date (2015-12-09) in the creationDate and now it's working.

Ok, that message wasn't terribly helpful.  In the future DaCHS will
be more explicit about its habits here.

     -- Markus


More information about the Dachs-support mailing list