Event-Timestamp issue when reading a detail file

[Aleš Rygl]

On 20. 05. 24 14:54, Alan DeKok wrote:
> On May 18, 2024, at 3:23 PM, Aleš Rygl <ales at rygl.net> wrote:
>>      I would like to kinldy ask for an help with following issue. I am running Freeradius 3.2.3+dfsg-2+b4 (Debian package) and have following problem. I receive Radius Accounting and put it into a a detail files. Then I have a detail file reader which stores Accounting records to DB. I have noticed a weird thing related to timestamp of the records. All records are inserted to DB with +1 hour offset. The attribute Event-Timestamp is logged correctly - when grepping detail files for the Event-Timestamp , it is fine, no offset.
>>
>> When I start Freeradius in debug mode, I can see that the packet is received as follows:
>    That's odd.  We have all kinds of tests for dates, and they all pass.  Plus, the time parsing code in src/lib/misc.c hasn't change between 3.0. and 3.2.
>
>    The underlying issue is that the OS functions which create times from structs (mktime() etc.) don't take time zones.  So they either (a) use the local time zone, or (b) use GMT / UTC.
>
>    This means that the time zone in the string is ignored, and the OS / C library functions treat the time as being from the local time zone.
>
>    So the two systems are either in different time zones, or one of them has the wrong time zone set.  i.e. the date was printed in CEST, but when it was parsed, the local time zone was CEDT.
>
>    We're working on fixing this in v4 by just removing the old-style time strings, and going to the RFC 3339 format.  The nice thing there is that the times / dates are now numerical, so there are no internationalization issues, either.

Thanks Alan.

Is there any way around this? I could use $S instead of Event-Timestamp, 
but that's no good. Would it be possible to manipulate the 
Event-Timestamp value with the expr module when reading the details 
file? Or when inserting into a DB where 
FROM_UNIXTIME(%{integer:Event-Timestamp}) is used. But it would have to 
respect  DST change.

Ales