hi,

is there any function that can give the CST datetime since 1970/01/01 to current datetime as milisecond.

I am using the following:

 
 [B]UTCTIME/HYYMDS   = HGETZ(8, 'HYYMDm');   STUTCTIME/HYYMDS = '19700101';   STDATEDIF/I9     = HDIFF(UTCTIME, STUTCTIME, 'DAY', 'I9');   HTIME_DATE/D12   = HTIME(8, UTCTIME, 'D12');   MILLISECOND/D20c = ((((STDATEDIF * 24) * 60) * 60)* 1000) + HTIME_DATE; [/B] 
 

the output is:
UTCTIME: 2016/07/27 05:45:43
STUTCTIME: 1970/01/01 00:00:00
STDATEDIF: 17009
HTIME_DATE: 20,743,316
MILLISECOND: 1469598343316

it is not looks like CST datetime

thanks,

This message has been edited. Last edited by: <Emily McAllister>,

In your code,

UTCTIME/HYYMDS   = HGETZ(8, 'HYYMDm');
STUTCTIME/HYYMDS = '19700101';
STDATEDIF/I9     = HDIFF(UTCTIME, STUTCTIME, 'DAY', 'I9');
HTIME_DATE/D12   = HTIME(8, UTCTIME, 'D12');
MILLISECOND/D20c = ((((STDATEDIF * 24) * 60) * 60)* 1000) + HTIME_DATE;

if you need millisecond accuracy, I would use /HYYMDm rather than /HYYMDS throughout.
-- But since
HTIME_DATE: 20,743,316
ends in 316 rather than 000, apparently assigning an 'HYYMDm' value to UTCTIME/HYYMDS left the milliseconds intact.

So what's your problem?

I wasn't aware of HGETZ being a function that provides the UTC date/time! It isn't documented in any of the documentation I've downloaded.

The posted code seems to be working, compared to the milliseconds shown on https://currentmillis.com/

DEFINE FILE CAR
LOCTIME/HYYMDs   = HGETC(8, 'HYYMDs');
UTCTIME/HYYMDs   = HGETZ(8, 'HYYMDs');
STUTCTIME/HYYMDs = '19700101';
STDATEDIF/I9     = HDIFF(UTCTIME, STUTCTIME, 'DAY', 'I9');
HTIME_DATE/D12   = HTIME(8, UTCTIME, 'D12');
MILLISECOND/D20c = ((((STDATEDIF * 24) * 60) * 60)* 1000) + HTIME_DATE;
END
TABLE FILE CAR
PRINT
LOCTIME
UTCTIME
STUTCTIME
STDATEDIF
MILLISECOND
COUNTRY NOPRINT
WHERE RECORDLIMIT EQ 1
END

This message has been edited. Last edited by: Francis Mariani,

Documented in v8.1.05, usable in v8.0.08:

WebFOCUS Release 8.1 Version 05 > Reporting Language > Using Functions > Date-Time Functions
WebFOCUS Release 8.0 Version 08 > Reporting Language > Using Functions > Date-Time Functions

quote:

the output is:
UTCTIME: 2016/07/27 05:45:43
STUTCTIME: 1970/01/01 00:00:00
STDATEDIF: 17009
HTIME_DATE: 20,743,316
MILLISECOND: 1469598343316

it is not looks like CST datetime

As Francis indicated, HGETZ gets UTC date/time (I didn't know that, either). But the original poster -- FRA-Sarwar -- is apparently expecting a local date/time. That is what function HGETC is for.

However... FRA-Sarwar's location is Kabul, Afghanistan, so I am left to wonder what the interest is in Central Standard Time (CST). Working remotely on a system in North America? Working with an international company that uses different time zones? It's hard to determine what answer to give in this situation.

I suppose the safe answer is to take the UTC date/time and subtract away six hours of time. In milliseconds that would be 6 * 60 * 60 * 1000 = 21600000.

1469598343316 - 21600000 = 1469576743316 (CST)

Of course, it's not quite that simple, since the UTC date/time that was given in FRA-Sarwar's example is today (2016/07/27 05:45:43), which means North America is using Daylight Saving Time. So it would actually be five hours subtracted from UTC instead of six, and it would technically be Central Daylight Time (CDT).

Since 1970/01/01 is the base date for ReportCaster and ReportCaster uses GMT times for scheduling and logging, I suspect FRA-Sarwar may be trying to set up a ReportCaster job running in a CST location that reads and reports from a ReportCaster log.