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.
Join the TIBCO Community TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.
From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
Request access to the private WebFOCUS User Group (login required) to network with fellow members.
Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.
I found an error in the procedure in my post "Reportcaster job activity", in relation with how timestamps are converted to date-time.
The RCaster database stores date-times as long. For example, a START_STAMP is stored as "1,334,554,346,693", which translates to "2012-04-16 07:32:26.693".
However, it turns out that the calculation to convert these values forgets to calculate in the fact that the EPOCH base-timestamp is based in GMT and not in our local time zone! The value I get from my calculation is: 2012-04-16 05:32:26.693 - two hours off!
How do I base EPOCH at GMT, with the other dates still based in local time?This message has been edited. Last edited by: Kerry,
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
That's not what I'm looking for, you just hard-coded those time-zones (w/o DST!) in your procedure.
The problem I'm facing is that EPOCH in GMT is a different date/time in local time depending on our DST.
Isn't there some built-in function to convert between those?!?
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
But that totally gets it wrong! You can't convert GMT to CET/CEST like that - GMT doesn't have daylight saving time (that's the whole point of it, after all), while CET/CEST do.
I'll keep on looking...
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
Golly, those are some interesting solutions! Thanks for posting that.
However, since I'm reading those integer timestamp values from a database, I'll just ask the database for the correct value. That's probably a lot easier...
I find it rather disappointing that WebFOCUS can't handle converting between different time zones of itself. It's got to be one of a few products that can't - heck, I think even my toaster can, but my toaster isn't very good at reporting.
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
I ended up using the difference between GETDATE() and GETUTCDATE() in MSSQL to calculate the local time zone offset relative to GMT:
SELECT
CAST(START_STAMP AS BIGINT)/1000 AS START_TS,
CAST(END_STAMP AS BIGINT)/1000 AS END_TS,
DATEDIFF(s, '1970/01/01 00:00:00', DATEADD(dd, 0, DATEDIFF(dd, 0, GETUTCDATE()))) AS TODAY_TS,
DATEDIFF(s, '1970/01/01 00:00:00', DATEADD(dd, 0, DATEDIFF(dd, 0, GETUTCDATE())) +1) AS TOMORROW_TS,
DATEDIFF(s, GETUTCDATE(), GETDATE()) AS GMTOFFSET,
JOB_DESC
FROM BOTLOG
WHERE ...
Note that START_STAMP converted to an integer type is larger than what an MSSQL int (4 bytes) can contain, so you need to cast to BIGINT (8 bytes) to prevent errors.
I put the above in a CTE (common table expression) for ease of use, but that requires adding the below setting to your procedure (or edasprof):
ENGINE SQLMSS SET CURSORS CLIENT
None of this was easy to find!
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :
Here's an update with a purely WebFOCUS based solution, now that we have HGETC and HGETZ in WF8.1. I'm using some of the simplified datetime functions from that release, but they easily translate to their less simple alternatives.
I abuse SYSTABLE as a dummy table to give me a single record that I don't use otherwise, it would make sense to use BOTLOG for this particular situation.
-SET &TS_BOTLOG = 1334554346693;
DEFINE FILE SYSTABLE
TS/P20.6 = &TS_BOTLOG/1000;
EPOCH_LOCAL/HYYMDm = DT('1970-01-01');
EPOCH/HYYMDm = DTADD(EPOCH_LOCAL, MINUTE, DTDIFF(HGETC(8, 'HYYMDI'), HGETZ(8, 'HYYMDI'), MINUTE));
END
TABLE FILE SYSTABLE
PRINT
EPOCH_LOCAL
EPOCH
TS
COMPUTE TSDT/HYYMDm = DTADD(EPOCH, SECOND, TS);
BY NAME NOPRINT
IF READLIMIT EQ 1
END
WebFOCUS 8.1.03, Windows 7-64/2008-64, IBM DB2/400, Oracle 11g & RDB, MS SQL-Server 2005, SAP, PostgreSQL 11, Output: HTML, PDF, Excel 2010 : Member of User Group Benelux :