[Avocado-devel] NRunner: decide on a "wire-format" for time/dates

[Beraldo Leal]

Hi Cleber, my comments below:

On Thu, Oct 31, 2019 at 1:24 PM Cleber Rosa <crosa at redhat.com> wrote:
> >   1. Is storage a problem?
>
> I would certainly like to save a few bytes on each message that
> contains a date/time, provided everything else is equal.
>
> But, to be honest, I don't think reading a JSON number as a date (say
> for Unix time) or a string (say for ISO 8601) would have a signficant
> impact on the transmission/processing/storage costs.  I think if we
> come to the point of needing to optmize the communication, a more
> comprehensive change, such as replacing the protocol/encoding
> altogether would probably yield the best results.

I agree.

> >   * On 32-bit systems there is the “Year 2038 problem”;
>
> This is trickier... and I hate to feel cornered by it.  Even if, to
> the best of my knowledge and assumptions, we won't be dealing with
> 32-bit systems by then, or, the problem would have been solved /
> worked around at another layer.
>
> <joke>TBH, you shouldn't had mentioned this!</joke>

Ohhh sorry! ;)

> >   * There is no limit on the number of decimal places for the decimal
fraction;
>
> Does this mean that a very high time resolution can be used?  This was
> one of the questions/concerns I had on the back of my mind...

Yes, because is supported by the format. But, as mentioned by Amador, we
are limited by the platform precision.

> > ## Examples using ISO 8601:
> >   * 2019-10-29T11:22:32+00:00
> >   * 2019-10-29T11:22:32Z
> >   * 20191029T112232Z
> >
>
> I like the last example a lot, but that is the one suggested by the
> standard notes to not be used, right?

Right.  The standard notes that "The basic format should be **avoided** in
plain text.".

I think that we if decide to use ISO-8601 because it is more
human-readable, we can add
few separators. ;)

It is important to notice that most of the common libraries that generates
ISO-8601 it will
output the string using the "extended format" with separators added to
enhance human
readability by default (if not format is specified).

> > If the answers to questions 1 and 2 are "no", I think that I would go
> > with ISO 8601 using 'Z' as UTC timezone, always.
> >
> > And you? Any thoughts? Do you have a third option?
>
> I think those two are the real contenders indeed.  I'm wondering if
> both formats shouldn't be supported by the status server when reading
> the messages, so that the writing of native runners would be
> facilitated and the load on them would be minimized.

Surely you know the user cases better than I do, but my suggestion
would be to choose a format and stick with it.

Sometimes, “premature optimization is the root of all evil.”
(Donald Knuth)

Regards,
-- 
Beraldo Leal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20191031/1c272301/attachment.htm>