dbinfo

I am currently using dbinfo("UTC_TO_DATETIME",connected) to convert the value in sysmaster:syssessions.connected to a datetime value for auditing purposes. Is there a function that will take that datetime value back to the UTC value to compare it against the value in sysmaster:syssessions.connected? Thank You, Nicole Guffey nguffey@jdriscoll.com

Nicole Guffey wrote: > > I am currently using dbinfo("UTC_TO_DATETIME",connected) to convert the > value in sysmaster:syssessions.connected to a datetime value for > auditing purposes. Is there a function that will take that datetime > value back to the UTC value to compare it against the value in > sysmaster:syssessions.connected? I posted a set of "C" functions for converting Informix Datetimes to/from various formats to the IIUG Software Repository last year. The file is called datefuncs.shar. Functions are provided to deal with Informix DATE and DATETIME types as well as UNIX time_t (ie UTC) through a unifying type (MyDateTime_t) which is three longs holding date (CCYYMMDD), Seconds since midnight, and microseconds (1/10^6) since tha last second. See the files mydate.c and mydate.h in that shell archive. Art S. Kagel

Nicole Guffey wrote: > > I am currently using dbinfo("UTC_TO_DATETIME",connected) to convert the > value in sysmaster:syssessions.connected to a datetime value for > auditing purposes. Is there a function that will take that datetime > value back to the UTC value to compare it against the value in > sysmaster:syssessions.connected? As an alternative to Art Kagel's C code, you could use a stored procedure instead -- at least until sometime in 2001: CREATE PROCEDURE dt_to_utc(dt DATETIME YEAR TO SECOND) RETURING INT; DEFINE i INTERVAL SECOND(9) TO SECOND; DEFINE s CHAR(10); LET i = dt - DATETIME(1970-01-01 00:00:00) YEAR TO SECOND; LET s = i; RETURN s; END PROCEDURE; Yes, you do have to use a string in there. The problem is that in 2001 sometime, the Unix clock moves from 9 digits to 10 digits, and 10 digits won't fit into an INTERVAL SECOND(9) TO SECOND variable. At that point, you have to do the reduction in two stages: 1. Deal in whole days and multiple by 86400 (24*60*60). 2. Deal in the hour to second part. More fiddly than difficult, but necessary for dates more than 30-odd years either side of 1970. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>