Hi Cleber, my comments below: On Thu, Oct 31, 2019 at 1:24 PM Cleber Rosa <cr...@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
