Re: Retry-After in UNIX Timestamp instead of HTTP-Date

interesting Idea also the advantage over the unixtime is that you dont get
to deal with the Year 2038 problem later if we are still having to deal
with systems too old/weird/whatever for 64 bit times

with one very small exception. a system which is unaware of the fault doing
a request shortly before the overflow with the retry stated for after the
overflow, but aside from that relatively short edge case nobody is going to
care whether the server clock is on 1901 or whatever unless we are dealing
with stuff that needs the absolute time (which this is not)

Am Di., 6. Aug. 2019 um 20:51 Uhr schrieb Wenbo Zhu <wenboz@google.com>:

>
>
> On Mon, Aug 5, 2019 at 11:59 PM Philipp Junghannß <
> teamhydro55555@gmail.com> wrote:
>
>> delay in whatever time unit needed is a good Idea, totally agree.
>> compatible to basically anything without needing to care for DST, leap
>> days/seconds or whatever, just a stupidly simple second counter.
>>
> And it needs to be a float type (32-bit) to support sub-second intervals.
> (also my earlier question on "Prefer: timeout= ...."  ... )
>
>
>
>> Am Mo., 5. Aug. 2019 um 14:06 Uhr schrieb Amos Jeffries <
>> squid3@treenet.co.nz>:
>>
>>> On 5/08/19 10:38 pm, Roberto Polli wrote:
>>> > Hi @all,
>>> >
>>> > While reading the Retry-After specs I was guessing...
>>> >
>>> > if we had to reboot the retry-after header, would we use the HTTP-date
>>> >  or the unix-timestamp syntax?
>>>
>>>
>>> Why re-design it at all?
>>>
>>> If anything reduce it to just the delay-seconds field value. That is
>>> compatible with any time locale.
>>>
>>> Amos
>>>
>>>