Re: A structured format for dates?

[Tommy Pauly <[e-mail]>]

On Aug 23, 2022, at 8:15 PM, Mark Nottingham <[e-mail]> wrote:
> 
> Personal response - 
> 
>> On 23 Aug 2022, at 11:27 pm, Tommy Pauly <[e-mail]> wrote:
>> 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.
> 
> It's important to remember that if/when we have binary structured fields, the binary wire representation can be different from the textual one we're defining now -- for example, it could be the same as that of an integer, but with a different type flag. 
> 
> What we're defining now is merely what the _textual_ (HTTP/1.1-ish) representation of a date is. The underlying data model for dates is separable (see below), as is its mapping to other serialisations of structured types.
> 
>> 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.
> 
> That entirely relies upon the precision of the underlying data model and the rules for transforming it to/from the textual representation. In the previous PR, the underlying data model was an integer, and the rules were fairly precise, so I don't think this is a strong reason to go this way.
> 
> This is why I'm not terribly convinced by the arguments for an integer textual representation so far; I think we can have the best of both worlds (integer data model / human-friendly textual representation) *if* we believe that binary structured fields are going to happen. IMO the only reason we'd choose an integer textual representation is if we didn't believe that.

It’s definitely fair that the binary version can be different. And it is certainly possible (as the previous version did) to make a rigorous set of rules for the date.

Ultimately, this is something that can indeed be spelled either way.

Two minor things that come to mind, that still make me prefer the @Integer format:

- If we expect to have binary header values in a future version (HTTP/4, say), we’ll have the same intermediary scenarios we have today with converting between versions. 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.

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

Best,
Tommy
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/