Bug 132225 - rule-based adapters with timeFormat always produce CBEs using "UTC" timezone.
Summary: rule-based adapters with timeFormat always produce CBEs using "UTC" timezone.
Status: CLOSED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: TPTP.monitoring (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: Dave Smith CLA
QA Contact:
URL:
Whiteboard: closed460
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-16 14:12 EST by Cindy Jin CLA
Modified: 2010-06-03 15:10 EDT (History)
0 users

See Also:


Attachments
Patch from Cindy Jin to fix this problem (11.52 KB, patch)
2006-04-03 00:46 EDT, Dave Smith CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Cindy Jin CLA 2006-03-16 14:12:02 EST
The rule-base adapters always output CBEs using "UTC" time zone. It doesn't use same time zone what the import log has. For example use log import wizard to import an apache access log file with 2.0.x (rules). The apache access log has records like:"9.26.157.44 - - [16/Jan/2003:21:22:59 -0500] "GET /WSsamples HTTP/1.1" 301 315". After import, the creation time is creationTime="2003-01-16T21:22:59.000000-00:00".
Comment 1 Cindy Jin CLA 2006-03-16 14:15:33 EST
Should be rule-based adapters always produce CBEs using "UTC/GMT" timezone.
Comment 2 Cindy Jin CLA 2006-03-16 14:48:22 EST
Correct problem description:
After import the creation time is "17-Jan-2003 2:22:59.000000 o'clock AM GMT+00:00".

The  creationTime="2003-01-16T21:22:59.000000-00:00" in first problem description, is the creationTime value of the exported XML format records by clicking the report button to export the log view records to an XML file. Another bugzillar is going to open for this.
Comment 3 Dave Smith CLA 2006-03-16 17:30:31 EST
This is a problem in the GLA run-time parser component where it uses the time format specified in the rules adapter file to parse a timestamp from the log record.  The original time zone from the log record is not persisted.  The timestamp is parsed into a Date object and converted into a long millisecond value.  This long value is then passed to the formatter to create the creationTime value in the CommonBaseEvent object.

To fix this the parser would need to create a string to represent the timestamp in the XML Date/Time format required by CBE that includes the same timezone offset as was included in the log record.
Comment 4 Dave Smith CLA 2006-03-17 18:00:47 EST
Changes are required in the following parser component methods:

org.eclipse.hyades.logging.adapter.internal.util.TimeParser.parse()
org.eclipse.hyades.logging.adapter.internal.parsers.SubstituteStatement.run()

The majority of changes are required in TimeParser.parse().  It needs to return a String instead of a long so SubstituteStatement.run() needs to change accordingly.  I believe the timezone offset can be retrieved from the Date object using the replacement for the deprecated Date.getTimezoneOffset() method as indicated at http://java.sun.com/j2se/1.4.2/docs/api/java/util/Date.html#getTimezoneOffset(). Then the timestamp string can be generated similar to how AbstractAccessLogParser.parseDate() does it.

The CBEFormatter requires no changes because it already handles createTime values as strings.
Comment 5 Dave Smith CLA 2006-04-03 00:46:28 EDT
Created attachment 37482 [details]
Patch from Cindy Jin to fix this problem
Comment 6 Dave Smith CLA 2006-04-03 00:48:10 EDT
Committed Cindy's changes to TPTP Head CVS.

Also needed to change ICUTimeParser with similar fix.
Comment 7 Paul Slauenwhite CLA 2009-06-30 12:17:33 EDT
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.