Problem with datetime and mysql

[ANGEL LUIS MATEO MARTINEZ]

By now, I have compiled from source, reverting that commit and this solves my problem. Thank you Allan.


--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868889150
Fax: 868888337

________________________________________
De: Freeradius-Users <freeradius-users-bounces+amateo=um.es at lists.freeradius.org> en nombre de Alan DeKok <aland at deployingradius.com>
Enviado: viernes, 15 de septiembre de 2023 14:05
Para: FreeRadius users mailing list
Asunto: Re: Problem with datetime and mysql

On Sep 15, 2023, at 6:33 AM, ANGEL LUIS MATEO MARTINEZ <amateo at um.es> wrote:
>
> I have also found that the detail stored in the detail file used in the buffered-sql is wright:
>
> Fri Sep 15 12:25:34 2023
> ...
>        Event-Timestamp = "Sep 15 2023 12:25:34 CEST"
>  ...
>        Acct-Delay-Time = 0

> but this is the processed detail shown with freeradius -X:
>
> detail (/datapool/radacct/acct_sql_log): Read packet from /datapool/radacct/acct_sql_log.work
>  ...
>        Event-Timestamp = "Sep 15 2023 13:25:34 CEST"
> ...
>        Acct-Delay-Time = 4294963801

  There are at a few issues here.  We changed the time parsing in 3.0.22 to allow it to parse dates in the local language:

https://urldefense.com/v3/__https://github.com/FreeRADIUS/freeradius-server/issues/3602__;!!D9dNQwwGXtA!VgZH90vJZmwboarLKjDT97b8qtMHPtPRXq4XP0751dy8ZZAtqFNRP6Bt8ETW2pT7bz3n7X7YzIy93eLo$

  This means that the server uses the time parsing functions from the local system.  In this case, those functions are returning the wrong thing.

  It's not clear how to fix this cleanly.  The time functions on your local system should work correctly.  If we swap back to the previous (internal) time parsing method, then it will break for people who use a non-English language.

  In most cases, we also want to print the strings in humanly readable form.  Because that's the easiest for everyone concerned.

  This issue is usually caused by time zone issues.  i.e. the detail files are in one time zone, but the local machine is running in a different time.  However, the local system here is both creating the detail files, and parsing them.

  So the conclusion is that the local time parsing functions are wrong, and create the wrong time.  I've pushed a workaround: https://urldefense.com/v3/__https://github.com/FreeRADIUS/freeradius-server/commit/1c00a9de25003566e970d0bca083eea7c3ea4087__;!!D9dNQwwGXtA!VgZH90vJZmwboarLKjDT97b8qtMHPtPRXq4XP0751dy8ZZAtqFNRP6Bt8ETW2pT7bz3n7X7YzOlV7AM9$

  This will avoid the issue by printing dates as integers, which can't be parsed incorrectly.

  I've also pushed a fix so that updates to the Acct-Delay-Time don't create extreme values.  Both of these fixes will be in the next 3.2.x release.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See https://urldefense.com/v3/__http://www.freeradius.org/list/users.html__;!!D9dNQwwGXtA!VgZH90vJZmwboarLKjDT97b8qtMHPtPRXq4XP0751dy8ZZAtqFNRP6Bt8ETW2pT7bz3n7X7YzCVbp7X6$