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
July 27, 2016, 01:17 PM
Francis Mariani
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.
Give me code, or give me retirement. In FOCUS since 1991
Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server
July 27, 2016, 02:20 PM
Squatch
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).
App Studio WebFOCUS 8.1.05M Windows, All Outputs
July 27, 2016, 02:54 PM
Dan Satchell
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.