Re: A structured format for dates?

[Poul-Henning Kamp <[e-mail]>]

--------
Roberto Polli writes:
> Hi Poul-Henning,
>
> Il giorno mar 23 ago 2022 alle ore 10:19 Poul-Henning Kamp
> <[e-mail]> 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.

Poul-Henning


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