From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Cary Huang <cary(dot)huang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: sslinfo extension - add notbefore and notafter timestamps |
Date: | 2024-03-20 14:28:47 |
Message-ID: | CAOYmi+nMSneR0XYr7Q_fvXtW5fbSEZ_Wt+1SxBHESZA-iMAxPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 20, 2024 at 7:03 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> The issue here is that postgres use a different epoch from the unix epoch, so
> any dates calcuated based on the unix epoch need to be adjusted.
Ah, thank you! I had just reproduced Cary's problem and was really confused...
> I've hacked
> this up in the attached v11 using overflow-safe integer mul/add as proposed by
> Jacob upthread (we really shouldn't risk overflowing an int64 here but there is
> no harm in using belts and suspenders here as a defensive measure).
>
> The attached v11 is what I propose we go ahead with unless there further
> comments on this.
One last question:
> + result -= ((POSTGRES_EPOCH_JDATE - UNIX_EPOCH_JDATE) * USECS_PER_DAY);
> + return TimestampTzGetDatum(result);
Is that final bare subtraction able to wrap around for dates far in the past?
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2024-03-20 14:28:53 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | Daniel Gustafsson | 2024-03-20 14:28:10 | Re: Refactor SASL exchange in preparation for OAuth Bearer |