Re: UTC Date Format

Hi Mike,

> We have a Cisco CallManager server that stores date/time in what they
claim
> is UTC format, for example "1074528964", which is some date/time in the
> recent past.

UTC is not a "format", it's a time zone.  "Universal Time Coordinated"
Sometimes called "Greenwich Mean Time".   Most systems store their time in
UTC, and convert it to the local time zone when displayed.  This allows
users to have different time zones configured yet have the time look
correct to them.  I believe that the iSeries even does this in V5R3.

> Is this format compatible with any data types on the AS400, or does it
need
> some massaging first?

My guess is that the time that they're sending you us actually the number
of seconds since "00:00:00 UTC, January 1, 1970".  This is a standard time
used by C programmers and Unix systems.

If so, the number you listed is "Mon Jan 19 16:16:04 UTC 2004"... or in
the Central timezone, that would be "Mon Jan 19 10:16:04 CST 2004"

Here's a trivial RPG program that converts the number of seconds to an RPG
timestamp field:

     D unixts          s             10U 0 inz(1074528964)
     D epoch           s               z   inz(z'1970-01-01-00.00.00')
     D ts              s               z

     c     epoch         adddur    unixts:*S     ts
     c                   dsply                   ts
     c                   eval      *inlr = *on

That timestamp will also be in the UTC timezone.  Unfortunately, there's
no good way (that I know of) to convert that time to the local timezone.
You could use an API like CEEUTCO to get the number of seconds difference
between the current timezone and UTC, and simply add that number of
seconds -- the problem is, CEEUTCO, (which is based on the system value
QUTCOFFSET) only knows what the UTC offset is AT THE MOMENT.  It doesn't
know what it was in January.  Thanks to the fact that you change the
timezone at daylight savings time, the number it returns might not be
correct.

To really solve the problem, you need to know whether it's currently
daylight savings time, and whether the date in question would've been
during daylight savings time -- and then adjust it by one hour (3600
seconds) if necesary.

Of course, you may not care that much... :)  I know I'd be content with
just reading the UTC time in a human-readable format...