Representations of time based fields

[fiestajetsam]

_{(this is specifically about retrofit, as I mentioned on the mailing list)}

Section 3.2 describes several headers where dates are present to use UNIX epoch seconds, and whilst this appears to be a good simplification and optimisation, using UNIX epoch seconds has a few issues such as no longer being human parseable, as well as either server or user-agent having to be able to compute UNIX epoch when sending it and deal with applying leap-seconds to get to UTC when parsing. Whilst this is unlikely to be an issue for the billions of UNIX based systems around the world, it's a new, subtle requirement all the same that someone (embedded systems in particular) may get caught out on.

So why not RFC 3339? It is both parseable by (trained) humans and machines, represents civilian time like that it replaces, and is a middle ground of gain in bytes reduced:

'Mon, 07 Feb 2022 19:11:07 GMT' = 29
'2022-02-07T19:11:07Z' = 20
'1644261067' = 10

This would likely require a bit more text to set some boundaries - maybe things such as week numbers and non-Zulu timezones should be discouraged? This also provides very optional millisecond resolution which some implementations already put into other custom headers.

[mnot]

So that would be a sf-string, which isn't very efficient to parse/serialise as compared to an integer -- keeping in mind that the longer term goal is a binary encoding of structured fields. Forcing a parse of data that's carried in a structured format also seems suboptimal.

That leaves two options:

1. Encoding as an integer
2. Defining a new structured type specific to dates

My thinking so far has been developer convenience alone isn't enough of a reason to mint a new structured type. Internet developers are broadly familiar with working with Unix epoch dates, and the learning curve is low (especially related to textual date formats).

[fiestajetsam]

If the priority is to focus on having both cross-version representation that is significantly more optimised than the incumbent (which I still disagree with), those two options do remain on the cards.

Going with the first option of encoding as an integer using UNIX epoch, then all the quirks* of leap seconds and the decrease in accuracy during positive leap seconds have to also be accepted - to be specific it means you cannot represent a value that occurs on a positive leap second and it's unclear what implementations may do differently serving a request in during one. Alternately not using this timescale and instead using UTC seconds tied to a known epoch may negate this, at the complexity of having to do some integer maths.

I would like to give some more thought to your second option , but are you referring to defining a type based on an existing primitive in RFC 8941 (e.g. using a sf-list or something), or defining a new type as extension? If it's the former, this may be optimal for binary encoding in HTTP/2, but significantly more bytes on wire and complex to generate/parse for HTTP/1. If it's the latter, what's to stop using RFC 3339 with markers to indicate a date format to parse it accordingly instead of first treating it like sf-string, or did you have another idea?

_{* if the differences are a bit unclear, the table in RFC 7164 §3.4 does a good job describing what happens during one}

[mnot]

I was more thinking of the latter - and indeed the textual representation could be 3339.

[fiestajetsam]

Well in that case, that works for me and I'd be happy to work on a PR for it - would it make sense to wait until after adoption call is closed and the Github and -00 formalities are done or do you have another idea?

[mnot]

Introducing a new type to SF would require writing an Internet-Draft and convincing the HTTP WG to adopt it.

As I said: personally, I'm not persuaded that the wire presentation of a field is important enough to justify a new type on its own -- especially when you consider that tools (e.g., DevTools) can show a more human-friendly representation when needed.