On Tue, Oct 29, 2019 at 5:14 PM Beraldo Leal <bl...@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 >