× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.