Thanks again Scott. In my particular case I am loading a file of VoIP call transactions coming from our Cisco phone system. They are storing the timestamp for the call time in unix UTC time. What I need to do with the data is display it to end-users (phone owners, supervisors, etc) and show the date and time the call was actually made. Most of them will have no idea what UTC time is and a fair number might not know how many hours eastern time is from UTC.
I think I got the code working to do this. Once I got it out of my head that it didn't need to be a one step process and I was lead to QWCCVTDT (and read the IBM documentation about 6 times) it wasn't that hard. Below is a snippet of what I did. I still have some testing to do to be sure but initial results look good.
/Free
// convert unix timestamp to iSeries datetime field
datetime = Jan011970z + %seconds(unixTime);
// adjust iSeries datetime field for local time zone from UTC
InputStruc.Date=%Int(%Char(%Date(datetime):*ISO0));
InputStruc.Time=%Int(%Char(%Time(datetime):*ISO0));
InputStruc.MicroSec=%SubDt(datetime:*MS);
CvtDateTimeFmt('*YYMD':
InputStruc:
'*YYMD':
OutputStruc:
dsErrCode:
'*UTC':
'*SYS':
dsTimeZone:
%Size(dsTimeZone):
'0');
// at this point OutputStruc.Date-Time-MicroSec has the local timezone adjusted values
/End-Free
D unixTime S 15 0
D Jan011970z C Z'1970-01-01-00.00.00.000000'
D datetime S Z
DCvtDateTimeFmt PR ExtPgm('QWCCVTDT')
D InputFormat 10 Const
D InputTS Const LikeDS(dsDateStruc)
D OutputFormat 10 Const
D OutputTS LikeDS(dsDateStruc)
D dsErrCode LikeDS(dsErrCode)
D InputTZ 10 Const
D OutputTZ 10 Const
D TimeZoneInfo LikeDs(dsTimeZone)
D TimeZoneInfoL 10I 0 Const
D PrecisionInd 1 Const
DdsErrCode DS Qualified
D BytesProvided 10I 0 Inz(%Size(dsErrCode.MsgData))
D BytesAvail 10I 0
D ExceptionID 7
D Reserved 1
D MsgData 128
DdsDateStruc DS Qualified
D Date 8S 0
D Time 6S 0
D MicroSec 6S 0
DInputStruc DS LikeDS(dsDateStruc) Inz
DOutputStruc DS LikeDS(dsDateStruc) Inz
DdsTimeZone DS Qualified
D BytesProvided 10I 0 Inz(%Size(dsErrCode.MsgData))
D BytesAvail 10I 0
D ExceptionID 7
D Reserved 1
D MsgData 128
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, September 17, 2007 5:36 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Converting Unix Jan 01 1970 UTC epoch datetime stamp to iSeries EST datetime stamp
Hi Mike,
Thanks Scott. Won't this convert the Unix time to a timestamp based
on the current date not the date in the unix timestamp?
The date & time will be the same date & time that are in the Unix
timestamp. However, the UTC offset will be based on the current UTC
offset, and not what the offset might've been when the timestamp was
created.
This is the way that Unix timestamps are normally dealt with. The idea
is to separate the actual date & time from the time zone. You keep
track of the actual date & time in a timestamp-neutral manner, and you
display them in the user's current frame-of-mind (which is the user's
local time zone.)
I've been programming in a Unix environment for a long time, and 99
times out of 100, that's what you do... you use the CURRENT time zone to
represent the date/time.
That way, if you use users in Uruguay and users in Colorado, both will
see the time in their own time zone, and can say "ahh, that time was 1
hour ago". (or whatever)
The other, much less frequent, part comes when you want to adjust the
date/time for the daylight savings time (or summer time) offset that the
date was (or will be) in. For example, if you want to say "Your account
will expire at 3:00 on Dec 14, 2007" then it's important to adjust for
the actual daylight/summer time setting that will be in effect on
December 14. In my experience, it's relatively rare that something
like this is needed, since usually you have something that expires on a
given DATE, and not necessarily at a particular time. The 1 hour
difference is usually negligible.
If this is an expiration date that the computer will deal with, you're
better off keeping things in UTC and never converting them. If it's for
a user to read and it'll be printed in advance, then it makes sense to
adjust it for the DST setting, but in my 15 years of Unix programming,
I've only had to deal with that once.
I guess you could convert it to a timestamp in the UTC zone, and use the
QWCCVTDT API to convert it.
The localtime() routine in ILE C might work as well... though, I've seen
this work differently on different platforms, and I haven't used it on
i5/OS yet, so YMMV.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
