Re: A structured format for dates?

> On Aug 23, 2022, at 4:00 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> Roberto Polli writes:
>> Hi Poul-Henning,
>> 
>> Il giorno mar 23 ago 2022 alle ore 10:19 Poul-Henning Kamp
>> <phk@phk.freebsd.dk> ha scritto:
>>>> Just tried to get some more feedback on twitter on the topic
>>>> https://twitter.com/ioggstream/status/1561752931417952258
>>>> feel free to RT.
>> 
>>> Making timestamps human readable is pointless, because, statistically
>>> speaking, no humans ever read these headers in the raw.
>> While statistically speaking humans do not read headers nor contents,
>> not having a human readable format for dates will just lead people that
>> cares for readability to:
>> 
>> - either continue using HTTP-date;
>> - or using a generic ISO8601 string, e.g. "2020-02-02T10:10:10+01:00".
> 
> And they are welcome to do that, so what's the problem ?
> 
> Again: Not even one out of a billion HTTP headers is ever read by a human,
> so insisting on human readability makes no sense.
> 
> For that one out of a billion, there is absolutely nothing preventing tools,
> for instance the browsers "developer tools" from nice-printing the field
> as human-readable.
> 
>>> The necessary handling of leap-second is complex and a layer-violation.
>> 
>> Syslog does not use them
>> https://www.rfc-editor.org/rfc/rfc5424.html#section-6.2.3
> 
> A: What does that have to do with anything ?
> 
> B: That is a really bad (13 year old!) choice, in a world where people have
>   started to apply leap-smearing and other platform-level mitigations of
>   leap-seconds.
> 
> Both HTTP and Syslog should transmit whatever time the platform provides,
> respecting whatever leap-second handling that platfrom has decided to apply.
> 
>>> And finally: it is much more expensive in terms of CPU power.
>> 
>> This makes the more computationally intensive HTTP-date
>> the only human readable option.
> 
> I literally dont know what that means ?
> 
> If only one out of a billion HTTP date headers are ever read by a
> human, and that is probably way overestimated, then clearly the
> extra processing cost of humanizing the field value should be
> borne only by those requests ?
> 
>> In general, I am not sure whether CPU power issues should be addressed at
>> a different level than field content (e.g. at messaging level) since it is
>> not possible to predict the spillovers of those micro-optimizations:
>> honestly I have no data on that. This is an interesting topic that
>> needs further (and proper) investigation though.
> 
> Well /I/ have experience with that, quite a lot in fact, and I'm
> telling you that converting to and from "human" timestamp format
> is a massive waste of computing power.
> 
> ...in particular when we are talking about a globally load-bearing protocol like HTTP.

The numeric type is not only simpler to process for a computer, but also should be generally smaller on the wire, particularly if we have binary structured fields one day. The scale of that alone can have a great impact.

I imagine it’s also a lot easier to translate *to* the human readable / localized format for a date from the number, since the number is an unambiguous form. Parsing dates the other way (from human readable to machine readable) is where much of the complexity and ambiguity arises, so a scheme that only requires transformations in one direction seems preferable. 

Tommy (no hats)

> 
> Poul-Henning
> 
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
>

Received on Tuesday, 23 August 2022 13:27:46 UTC