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

Beraldo Leal bleal at redhat.com
Tue Oct 29 16:14:30 UTC 2019


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?

[1] - https://trello.com/c/w4iFhDfM

Regards,
-- 
Beraldo Leal
Senior Software Engineer, Virtualization Team
Red Hat




More information about the Avocado-devel mailing list