Ok. RFC says exactly that
"The Value field is four octets encoding an unsigned integer with
      the number of seconds since January 1, 1970 00:00 UTC."

I did not think radiusd rewrites unix timestamp into date.
Just because previous radius i was using used to put the timestamp into accounting as an integer.


Moreover i did not notice this helpful trick in variables.txt:

"     %S       request timestamp
                in SQL format"

Does it mean that %S takes the timestamp from the Event-Timestamp field of the accounting packet?

--
SY,
Alexander

Alan DeKok wrote:
Alexander <[EMAIL PROTECTED]> wrote:

This RFC says the attribute to be unsigned integer. Why is it "date" in dictionary.rfc2869?


  Because it's a date.  See RFC 2866 for a definition of the "time"
type.  It's the same as "date", and is stored as a 32-bit integer.


If we name the file with rfc number, then why didn't we follow it ?
It's not difficult to change the attribute every time i upgrade, but ...


  Why the heck are you changing the attribute?  It's a date.  It gets
printed and parsed like a date.  What goes into the RADIUS packet is a
32-bit integer, because that's how dates are represented in the
protocol.

  Do you really want to see and type in all dates in your system as
32-bit integers?  That's how they're represented internally in Unix.

  I'm at a complete loss for why you would want to change the type of
the attribute.  What do you hope to gain by it?

  Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to