Re: A structured format for dates?

+1 to Tommy "no hats" Pauly's rational

On Tue, Aug 23, 2022 at 7:30 AM Tommy Pauly <tpauly@apple.com> wrote:

>
>
> > 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.
> >
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._