Re: A structured format for dates?

+1 on the integer format. Every boundary between every pair of existing
HTTP-based systems handles the textual representation of HTTP headers.
Boundaries between systems are hard to change, so we should expect binary
structured fields will, at best, succeed in a few key boundaries where
we're willing to put the effort into migrating. The rest will pay the costs
of the textual representation, from size to complexity to interop risk.
(It's not too hard to accidentally accept, say, June 31st as an alias for
July 1st. Calendar math is messy.)

On Wed, Aug 24, 2022 at 9:55 AM Ryan Hamilton <rch@google.com> wrote:

> I'm sold on the arguments that an integer format is the way to go.
>
> On Wed, Aug 24, 2022 at 1:41 AM Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
>
>> --------
>> Mark Nottingham writes:
>>
>> > IMO the only reason we'd choose an integer textual representation is if
>> we
>> > didn't believe that [binary structured fields are going to happen].
>>
>> I disagree.
>>
>> First, we are never going to get 100% penetration for a binary
>> serialization,
>> and it will take about five years for any significant uptake of it.
>>
>> Second, the efficiency arguments are invariant of the existence of
>> binary serializations, because most of the actual HTTP header
>> processing HTTP headers will not operate on the binary serialization
>> in the first place.
>>
>> Third, there are many efficiency arguments for integer textural
>> representation,
>> even without considering binary serializations:
>>
>> * takes up less space in files and on the wire
>> * compresses better.
>> * is faster and uses less instructions/energy to produce and parse
>> * is easier and less error-prone to produce and parse
>>
>> So I really dont see binary structured fields as particularly relevant
>> for this
>> decision, if anything, they just add one more efficiency argument:
>>
>> * is faster/uses less instructions/energy and easier to (de)serialize as
>> binary.
>>
>> 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.
>>
>>