We need to compute the timestamp in Kea so stat we don't need to do multiple
selects.
Imagine the scenario:
1. get data from database (including timestamp)
2. if no lease, generate a timestamp and do insert
3. if any further update is necessary, we use the in RAM timestamp to make sure
the row i
Marcin, you are right, the timezones must match, so it is ok to use different
timezone, as long as this is consistent between kea and database, but the
previously mentioned restrictions regarding DNS code, it means that the
internal time must be UTC, so this means that all must be UTC.
I don't
I have opened https://gitlab.isc.org/isc-projects/kea/-/issues/1968 to address
this.
mysql uses localtime_r and mktime, so conversion from/to UTC to local timezone
is done internally by kea server.
postgres uses only locatime_r, but does not use mktime to convert the UTC in
local timezone, and
What I don't understand is why you didn't just use a straight UTC timestamp in
an int or bigint field. You can add said timestamp right in your sql query as
unix_timestamp(now()) which will produce an EPOCH time in the column. If you
need to see it as an actual date/time for some reason, you w
Razvan,
It is correct that the timezone used by Postgres and the timezone used
by Kea must match, but they don't necessarily have to be UTC.
Kea creates a timestamp using time() function. The output is in UTC.
Then the Postgres backend converts it to local time using localtime_r()
(that's where K
It was a timezone issue. Both ends now on the same Timezone and Kea is now
re-issuing addresses.
Thank you.
Gordon.
From: Razvan Becheriu
Date: Wednesday, 7 July 2021 at 19:37
To: Jeronimo
Cc: Gordon Ross , Kea-users@lists.isc.org
Subject: Re: [Kea-users] Unable to re-allocate address
Hi,
