Cannot parse gc log where first line does not have a timestamp

[dsgrieve]

Describe the bug
Log file begins with

 [Times: user=0.45 sys=0.00, real=0.05 secs] 
2021-12-17T19:04:11.194+0000: 302396.015: [GC pause (G1 Evacuation Pause) (young)
Desired survivor size 742391808 bytes, new threshold 15 (max 15)
- age   1:   27289544 bytes,   27289544 total

Parsing silently fails with

Dec 17, 2021 3:05:57 PM com.microsoft.gctoolkit.event.g1gc.G1Trap trap
INFO: Internal EventSource Error @ @0.000
Dec 17, 2021 3:05:57 PM com.microsoft.gctoolkit.parser.PreUnifiedG1GCParser record
WARNING: Parsing Error: Attempt to record Trap @0.0

Removing the first line of the log resolves the issue, but gctoolkit should be able to handle this.

I have asked the originator of this issue to attach the log file here.

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Still Relevant

• Summary: This bug is still present in the current codebase. The parser code that fails when the first line of a GC log lacks a timestamp has not been fixed.

• Evidence:

  • PreUnifiedG1GCParser still exists at parser/src/main/java/com/microsoft/gctoolkit/parser/PreUnifiedG1GCParser.java and still uses G1Trap for error handling.
  • G1Trap still exists at api/src/main/java/com/microsoft/gctoolkit/event/g1gc/G1Trap.java and still logs the same "Internal EventSource Error" messages described in the issue.
  • The root cause is in PreUnifiedDiarizer.timeOfFirstEvent() (line 236–248 of PreUnifiedDiarizer.java): when the first line (e.g., [Times: user=0.45 ...]) doesn't match the DATE_TIMESTAMP_RECORD pattern, timeOfFirstEvent stays null through the diarize phase, then defaults to new DateTimeStamp(0.0d) at line 232 — leading to the @0.000 timestamp in the error output.
  • No commits on main have addressed this issue. The repository's single commit (7e86099) is unrelated (workflow fix).
  • A related open issue NullPointerException when processing file without GC Events #359 and PR Issue #359: fix NPE when parsing gc log file without any events #409 deal with a similar but distinct problem (NPE when a log file contains no GC events at all), but neither addresses this issue's scenario of a valid log with a non-timestamped leading line.
  • No duplicate issues were found covering this exact bug.

• Recommendation: ✅ Keep open — The bug is confirmed to still exist in the current code. The PreUnifiedDiarizer does not skip or gracefully handle leading lines without timestamps (such as a trailing [Times: ...] fragment from a previous log rotation). This is a valid, actionable parser robustness improvement.

Generated by Relevance Check Agent for issue #196