[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