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

[Amador Pahim]

On Tue, Oct 29, 2019 at 5:14 PM Beraldo Leal <bleal at redhat.com> wrote:
>
> Hi all,
>
> So, we have a Trello card [1] to discuss what date/time format we are
> going to adopt when saving date/time on a file.
>
> I'm moving the discussion here because it seems better to discuss here
> than on Trello.
>
> When it comes to date/time storage format, I can think of two very
> well-used standards: 1. Unix Time and 2. ISO 8601.
>
> I’m in favor of the “disambiguation” feature. Read a date/time and not
> have to guess which timezone is a plus.
>
> I think that few questions should be answered before we decide this:
>
>   1. Is storage a problem?
>   2. Is a CPU bound problem to parse this date/time?
>   3. Who is going to read this information? Machine or human?
>
> I believe that by answering these questions, we can go smoothly with
> one format or another, as all languages have libraries to handle it.
>
> I have listed below the advantages and disadvantages that I have been
> able to collect so far. Feel free to add or comment about.
>
> # Unix Time / Posix Time / Epoch Time
> ## Advantages:
>   * Better for machine readability;
>   * Optimized for storage;
>   * Very well-known with builtin libraries in many languages;
>
> ## Disadvantages:
>   * No timezone support (assumes UTC);
>   * Leap seconds are ignored;
>   * Cannot store values before “1970-01-01 00:00:00 UTC”;
>   * On 32-bit systems there is the “Year 2038 problem”;
>
> ## Examples using Unix Time:
>   * 915148800.25
>   * 1095379201.00
>
> # ISO 8601
> ## Advantages:
>   * Better for human readability;
>   * Very well-known international standard with builtin libraries in
> many languages;
>      (First edition in 1988 and updated until nowadays);
>   * UTC time zone can be represented by only one “Z” char;
>   * The lexicographical order of the representation thus corresponds
> to chronological order;
>     (except for date representations involving negative years or time offset);
>   * A fraction may be added to the lowest order time element in the
> representation.
>     (A decimal mark, either a comma or a dot can be used);
>   * There is no limit on the number of decimal places for the decimal fraction;
>   * Has support for a basic format (without - or : ) and an extended
> format with separators added to enhance human readability
>   (The standard notes that: "The basic format should be avoided in
> plain text.");
>
> ## Disadvantages:
>   * Needs more time to parse (not so optimal for machine parsing);
>   * Needs more space to store;
>
> ## Examples using ISO 8601:
>   * 2019-10-29T11:22:32+00:00
>   * 2019-10-29T11:22:32Z
>   * 20191029T112232Z
>
> 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?

About precision (mentioned in the trello card), no matter the format
you pick, it all starts with an epoch on a float with the maximum
precision provided by the platform (time.time()). So one cannot get
more precise than that, afaik.

About format, I'd expect it to be either an epoch, so I do all the
conversions myself, or an ISO-8601 in my localtime so I don't do any
conversions. An ISO-8601 in UTC is something in between: I can read,
but I have to convert so it makes sense.

But the best of both worlds would be, IMO: let users decide. Get epoch
internally with time.time(), then allow users either use it as is or
to format it from the avocado.conf, using the time.strftime()
formatters, defaults to ISO-8601:

[nrunner]
# datetime: epoch or asctime (defaults to asctime)
datetime = asctime
# datefmt: asctime formatters using strftime (defaults to ISO-8601 format)
datefmt = '%Y-%m-%d %H:%M:%S'

"epoch" would give users time.time().
"asctime" would give users time.strftime(datefmt, time.localtime(time.time()))

wait, that's what the logging module does, isn't it? :)

My 2 cents.

>
> [1] - https://trello.com/c/w4iFhDfM
>
> Regards,
> --
> Beraldo Leal
> Senior Software Engineer, Virtualization Team
> Red Hat
>