Re: A structured format for dates?

I agree that we'd be *very* much out on a limb if we don't adopt an already defined model for time.

So, that returns us to the original question --  whether we need a distinct data type in SF for dates. As far as I can tell, the distinguishing issue is whether knowledge of the specific header is needed to create a human-friendly representation of it.

If dates are Integers (or Decimals), someone examining that field will need to know that the Integer/Decimal represents a date to be able to present it. Tools could have a list of such fields, but they'd need to be updated from time to time (or have a way of manually flagging a field as a date).

If dates are their own distinct data type in SF, the underlying data model would still be an integer or decimal, but it would self-identify as a date, so that tooling could identify it as such automatically.

When we originally did SF, personally I was unconvinced that the benefit of automated recognition for the purpose of human-friendly presentation was compelling enough to justify a separate data type; the set of date-oriented fields is relatively small, and in most cases the application in question *does* have knowledge of the field's semantics when handling it. The only exception might be generic debugging tools, but again, not terribly compelling.

I'm happy to change my mind if folks feel differently, or (especially) if there's another compelling reason to have a date-specific type. However, I'm seeing pushback from the HTTPAPI folks about having *anything* that doesn't look exactly like the Sunset header field (which IMO is shortsighted), and so far it seems like most folks here are happy with the direction that we currently have in Retrofit -- using Integer (or Decimal). 

I'm going to make one final proposal in HTTPAPI to see if that changes any minds, but if not I think we should close this issue.

Cheers,


> On 17 Jun 2022, at 3:31 pm, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> 
> --------
> Austin William Wright writes:
> 
>> I don't believe 'works 99.999998% of the time" may be 
>> good enough.
> 
> Well, that's what everything based on POSIX offers today.
> 
> Trying to compensate for that deficiency in the HTTP layer is
> counter-indicated:  We should take, and trust, the time from the
> platform we run on, and handle leap seconds however that platform
> does.  If the platform jumps over leap-seconds, we should
> follow it, if it smears over them, we should slide along.
> 
>> Rather, if support for fractional seconds is important for any reason at 
>> all, [...]
> 
> Last we talked about it, the CDN people really wanted it for things like
> Cache-Control etc.
> 
>> Let me propose a different argument for your case: UTC is inherently 
>> discontinuous, [...]
> 
> and all HTTP relevant practical realizations of UTC have variable
> frequency.
> 
> But again: Inventing a new time-keeping paradigm for HTTP is a non-starter.
> 
> -- 
> 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.

--
Mark Nottingham   https://www.mnot.net/

Received on Friday, 17 June 2022 05:47:34 UTC