Re: A structured format for dates?

[David Benjamin <[e-mail]>]

On Thu, Aug 25, 2022 at 11:21 PM Mark Nottingham <[e-mail]> wrote:

>
> > On 24 Aug 2022, at 1:32 pm, Tommy Pauly <[e-mail]> wrote:
> >
> > - If we expect to have binary header values in a future version (HTTP/4,
> say),
>
> Aside - I think this can be negotiated as an extension, rather than
> requiring a full new version.
>
> > we’ll have the same intermediary scenarios we have today with converting
> between versions.
>
> Correct.
>
> > Certainly we could use the rules to correctly convert between the
> date-text version and the numeric version, but it would be more complexity
> than just moving an integer value over (and handling an @ or marking a
> flag), and buggy implementations may lead to values being closely
> translated but not perfectly translated.
>
> Absolutely -- and that's true for parsing existing dates and translating
> them into an integer as well.
>

Parsing existing dates isn't really a function of our format. Whatever
format we pick, the system will need to extract and store dates with its
existing format, be it something expanded or a simple integer
representation. That cost will be paid no matter what format we pick.

The question is what *additional* cost do we impose by our choices, to
convert from the in-memory representation to/from HTTP structured headers.
Converting to/from a date-text representation has a long history of
complexity and problems. (Just recently I had to review a whole new
implementation of calendar conversions because it turns out libc
implementations of timegm have patchy availability and poor performance.
And if you've never seen how browsers parse the HTTP Date header, you
should take a look sometime. It's truly spectacular.)

Converting a textual integer representation is much simpler by comparison.


> > - If the benefit we’re providing by using the date-text format is to
> make things more easily human readable, I’ll likely want to have the choice
> to view the date while debugging in whatever timezone I prefer and using
> whatever date presentation format I prefer. So, the tools will ideally be
> translating the value anyway.
>
> Possibly, although as Julian says, many will be looking at the 'raw' or
> 'default' text.
>
> Another factor that I've been keeping very much in mind is adoption --
> whether the format's readability in HTTP/1.1 will affect decisions as to
> whether to adopt the type (e.g., HTTPAPI). That's hard to predict in the
> long run, unfortunately.
>

That applies to all the arguments here. As you say, we have to pay for the
HTTP/1.1 format even if binary structured headers happen. Readability
affects decisions, but so does interoperability, size, and complexity. I
certainly will be disinclined to use this format in HTTP systems I help
design, if the format is likely to lead to interop mess, or needlessly
waste cycles.

David