Hi Paul,
The stat() API keeps it's access, change, and modification times as a
count of seconds since Midnight on January 1st, 1970 UTC. The "UTC"
part is important... You may think of UTC as "GMT" (Greenwich Mean
Time). That means you need to adjust the timestamp for your time zone.
Personally, I use a routine like this:
*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
* Convert Unix timestamp to RPG timestamp
*
* Call this with the data returned by stat() or Qp0lGetAttr
* convert to an RPG timestamp field.
*+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
P Unix2Rpg B
D Unix2Rpg PI Z
D UnixTime 10U 0 value
D CEEUTCO PR
D Hours 10I 0
D Mins 10I 0
D Secs 8F
D fc 12A options(*omit)
D Epoch c z'1970-01-01-00.00.00'
D TimeZone s 10I 0 static inz(-1)
D Hours s 10I 0
D Mins s 10I 0
D Secs s 8F
D retval s Z
/free
if (TimeZone = -1);
CEEUTCO(Hours: Mins: Secs: *omit);
TimeZone = secs;
endif;
retval = Epoch;
retval = retval + %seconds(UnixTime) + %seconds(TimeZone);
return retval;
/end-free
P E
Assuming your system's time zone (or UTC offset if you're on an old
release) is set correctly, this should return the proper time for the
IFS file.
Some people have criticized this routine, because they want the
timestamp to be returned in the time zone as it was at the time the file
was accessed/updated/modified. I disagree, but I'm weird.
For example, if a user updated an IFS file on July 1st, 2011 at 3pm, if
I ran my Unix2RPG routine on the "st_atime", I'd get this result:
z'2011-07-01-14.00.00.000000'.
That confuses people... they say "but, I ran it at 3pm, why does it say
14, which is 2pm?" Well, because on July 1st it was Daylight Saving
Time, and our time zone (Central time) was 5 hours behind UTC. But now
it's not daylight saving time, and so our time zone is 6 hours behind UTC.
Why is that a good thing? Becuase if I do %diff( %timestamp: IfsTime:
*HOURS) my result will be accurate. But it's a bad thing, because
people don't think of their current time as an offset of UTC. They
think of their current time as "the normal time", and UTC as "some weird
thing that only geeks like Scott care about."
The QWCCVTDT API could be used to code around this if you wanted to.
On 2/2/2012 5:10 PM, Paul Therrien wrote:
Does anyone know how to convert the time values that are returned from the
stat() IFS api for an IFS file.
If anyone knows I would appreciate finding out the formula or finding out
where the information is. The IBM site has not been very forthcoming
I want to be able to display from within my RPGLE program the create date
and time of the IFS file to help the user determine the exact file they are
after.
Thank You Scott Klement for your IFS API e-book. You have saved me lots of
time. Your examples and code are just excellent.
midrange.com
