[Fuego] JSON schema and examples for Fuego's run.json format

Bird, Timothy Tim.Bird at sony.com
Fri Jun 30 21:52:52 UTC 2017


> -----Original Message-----
> From: Milo Casagrande
> 
> On Fri, Jun 30, 2017 at 2:47 AM, Bird, Timothy <Tim.Bird at sony.com> wrote:
> >
> > The RFC3339 spec only allows 1 digit of fractional seconds,
> > according to my reading of the spec.  I believe ISO8601 allows
> > more fractional seconds digits, but I'd like to stick to a strict
> > subset of ISO8601 for the reasons mentioned in RFC3339.  I dug
> > into this today (in probably too much gory detail)
> > and Python and C support for RFC3339 is kind of messed up.
> >
> > See my notes on this at:
> > http://bird.org/fuego/Issue_0047
> >
> > I'm working on a patch that uses timestamps in the following format:
> > $ date +F_%T%z
> > 2017-06-29_17:44:25-0700
> >
> > This is not strictly compliant with RFC3339, so might be different than what
> > kernelCI expects, but I have reasons for my deviations.
> 
> Hmmm... I'm not sure I see the necessity for that deviation.
> That date string (with an underscore instead of the T character) will
> results in errors even in JavaScript.
> 
> Since it's JSON and it is based off JavaScript, the date format that
> JavaScript can expect is also based on a simplified version of
> ISO8601: YYYY-MM-DDTHH:mm:ss.sssZ [1] (it also accepts an RFC2822 date
> format).
> 
> Although JSON is a human readable data format, it still is a machine
> data-interchange format. IMHO, I wouldn't deviate much from the
> expected format.
> Application that uses the JSON data can then visualize the date (and
> the data in general) in a more human friendly way.

OK.  Thanks for the info.  I agree with your points.  It looks
like Javascript's strict interpretation of the date/time delimiter ('T')
will trump my desire for a more white-spacey delimiter for
human readability.  I assume that Javascript can handle
seconds with no fractional component?

I can always do a conversion of 'T' to '_' when the timestamp is
used for directories or filenames, if it seems really important
(which it doesn't at the moment).

As for the timezone offset, it's unclear to me whether the spec calls
for colons or not.

According to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

Given a string representing a time, parse() returns the time value. It accepts the RFC2822 / IETF date syntax (RFC2822 Section 3.3), e.g. "Mon, 25 Dec 1995 13:30:00 GMT". It understands the continental US time zone abbreviations, but for general use, use a time zone offset, for example, "Mon, 25 Dec 1995 13:30:00 +0430" (4 hours, 30 minutes east of the Greenwich meridian).

(this example has no colon in the timezone offset)
----
According to https://tools.ietf.org/html/rfc2822#section-3.3

zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

(This spec is quite strict and does NOT use a colon.)
-------------
However,
According to http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15

Z	is the time zone offset specified as “Z” (for UTC) or either “+” or “-” followed by a time expression HH:mm

(Note the use of a colon.)
-------------
Doing it without a colon is easiest from shell or python, but I'm not sure about Javascript.

What do the timestamps look like in kernelci - do they have colons or not in the timezone?
Or are all times expressed in UTC ('Z') values?

------
Thanks very much for the feedback.
 -- Tim


More information about the Fuego mailing list