Unified logs missing time stamps causes NPE

Unified GC logs without a timestamp will cause NPE as all of the code expects a timestamp. Use first date stamp as a base of 0.000 seconds and then synthetically generate timestamps for each JVMEvent.

[brunoborges]

/relevance-check

[github-actions]

Relevance Assessment: Still Relevant

• Summary: The NPE caused by missing timestamps in unified GC logs has not been fixed in the current codebase. The proposed approach of synthetically generating timestamps is also not implemented.

• Evidence:

  • In GCLogParser.java:55, this.clock = diary.getTimeOfFirstEvent() can set clock to null when no timestamp is present, since Diary.getTimeOfFirstEvent() simply returns the field which may never be set.
  • In GCLogParser.java:123, getClock().add(lastDuration) will throw an NPE when clock is null.
  • The Decorators.java TODO comment (lines 55-57) explicitly acknowledges the gap: "If both [uptime and time] are missing, GCToolkit JVMEvents will have no sense of time."
  • No synthetic timestamp generation logic exists anywhere in the codebase, as proposed in this issue.
  • Related but distinct: Issue NullPointerException when processing file without GC Events #359 covers NPE when a log has no GC events at all (different root cause). PR Issue #359: fix NPE when parsing gc log file without any events #409 proposes a fix for that case but remains open and unmerged, and does not address the missing-timestamps-with-events scenario described here.
  • Issue NPE in Aggregation.estimatedStartTime() when processing a Pre-Unified GC log with timestamps only. #340 (closed) was a different NPE in Aggregation.estimatedStartTime(), resolved as a user configuration error.

• Recommendation: ✅ Keep open — The bug is reproducible in the current codebase. The clock field can become null when unified logs lack timestamp decorators, and there is no fallback or synthetic timestamp generation. This issue remains valid and actionable.

Generated by Relevance Check Agent for issue #274