Re: A structured format for dates?

[Toerless Eckert <[e-mail]>]

Added:

I like structured format. There are a lot of diagnostics and other software that would not want to do additional transcoding of header elements but just represent them verbatim as they occur. Those are helped if the verbatim representation is already easier readable.

I do not think TZ belongs into a time/date representation. Aka: all date/times in UTC please. TZ can be added somehow as a "location" information, ideally in a different header field. If it is in the same header field, it would be confusing to show the time in UTC but ALSO to indicate the TZ. Maybe this can be resolved by coming up that would make it as obvious as possible that the date/time is NOT adjusted for the TZ shown. Maybe not call it "TZ" but "LOC" so that the "the date/time it TZ adjusted" recognition is not triggered. And of course waste the three characters on "UTC" in the representation.

I do not believe the processing speed argument to be valid. The level of processing speed where just a (sub)second unstructured value would help goes IMHO into the space of CoAP, not HTTP. I'd first try to make HTTP better where it does not just duplicate CoAP efforts. All that binary stuff CoAP needs to do is severely making toolchains more complex IMHO.

I do like the leap-second argument.

I do think msec accuracy should be an option. RTTs within lan/metro environments can easily be in the single digit msec range and you want to be able to diagnose e.g.: REST based broker/bus-type transaction speeds, relative ordering of request/replies.

Cheers
    Toerless

On Thu, Jun 16, 2022 at 08:22:11AM +0200, Willy Tarreau wrote:
> On Thu, Jun 16, 2022 at 04:04:52PM +1000, Mark Nottingham wrote:
> > Personally, I tend to agree with PHK - I think that Integer (or Decimal) is
> > adquate and appropriate.
> 
> +1 for me!
> 
> > However, some people seem to keep on pushing back on this - I think
> > especially for application-focused headers it's more visible. If we're going
> > to do something, retrofit is a good opportunity for it, since we're defining
> > SF-Date and friends.
> 
> The thing is, the effort to present *any* human-readable string is always
> worse than converting an integer (or decimal) to the final representation,
> since it's required to pass through such an integer-based representation
> at one point during the operation anyway.
> 
> The epoch-based representation also has the benefit that you're not required
> to have to guess a timezone nor to be confused by ":60" resulting from a leap
> second once every few years.
> 
> Also, applications that want to rely on text-based dates do not all agree
> on the format. Some would like to see the day-of-week there, others don't
> want ISO8601 because it's less readable by humans etc. Thus I'd rather go
> for integer+fraction only.
> 
> Cheers,
> Willy

-- 
---
[e-mail]