Hi Lon,
The bahaviour you are seeing is because the normal behaviour of
"integer-date" is to make an SQL date/time with 0 seconds.

Its this way to be compatible with some other more braindead SQLs.

If you are at Radiator Revision 2.13, look at the new formatted-date type in
AcctColumnDef, where you can build an SQL date in any format you like.

Hope that helps.


Mike McCauley                                 [EMAIL PROTECTED]
Open System Consultants                 +61 3 9598 0985

Mike is travelling right now, and there may be delays
in our correspondence.
-----Original Message-----
From: Lon R. Stockton, Jr. <[EMAIL PROTECTED]>
Date: Tuesday, March 02, 1999 1:40 PM
Subject: (RADIATOR) timestamp

>I've got radiator configged to only do auth stops, and to stash the
>info with SQL. One of my colums is thus:
>    AcctColumnDef STOPTIME,Timestamp,integer-date
>My database is PostgresSQL (running under Linux), and the column
>is defined as 'STOPTIME timestamp not null'.
>Everything is almost cool. I note that the timestamps recorded in
>the database are always approximately equal to the timestamp I see
>in the detail file (minus Acct-Delay-Time)...but the seconds are
>'truncated', that is, the timestamp recorded always has the seconds
>set to '00'.
>I actually can live with it, but it's probably something blindingly
>obvious that I should know...and one year hence, I'll probably be
>ashamed I ever wrote this message, but I gotta know...what's going
>on here? Resolution issue in postgres's implementation of timestamp?
>Radiator? Me?
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.

To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to