As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only. Moving forward, myibi is our community platform to learn, share, and collaborate. We have the same Focal Point forum categories in myibi, so you can continue to have all new conversations there. If you need access to myibi, contact us at firstname.lastname@example.org and provide your corporate email address, company, and name.
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?
- Jack Gross WF through 8.1.05
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005
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).
App Studio WebFOCUS 8.1.05M Windows, All Outputs
Posts: 594 | Location: Michigan | Registered: September 04, 2015
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.
Posts: 1213 | Location: Seattle, Washington - USA | Registered: October 22, 2007