'jfr print' doesn't take into account daylight savings time. This can most easily be seen when printing to JSON or XML.

This happens because JFR writes TimeZone::getRawOffset() to the file, which is then used to construct OffsetDateTime objects. The use of getRawOffset() is legacy from before java.time existed.

Example, a recording created in July 27, 23:42:50 in the CET time zone results in this:

      "type": "jdk.LongFlag",
      "values": {
        "startTime": "2022-07-27T22:42:50.804383083+01:00",
        "name": "ThreadStackSize",
        "value": 2048,
        "origin": "Default"
      }

It should be:

      "type": "jdk.LongFlag",
      "values": {
        "startTime": "2022-07-27T23:42:50.804383083+02:00",
        "name": "ThreadStackSize",
        "value": 2048,
        "origin": "Default"
      }

The raw offset today is stored in a field called "gmtOffset" in the Metadata event.

One way to fix this is to add TimeZone::getDSTSavings() to "gmtOffset" when the recording is written.

Another is to add a new "dst" field (will not break the file format) and then update the parser so it adds gmtOffset and dst before constructing an OffsetDateTime.

A benefit of the first way is that older version of the JDK can print newer recordings correctly. A drawback is that meaning of gmtOffset field is changed. It will not break JMC, because it doesn't read the field, but it doesn't seem proper to change the meaning, possibly in an update release if the fix is backported. If the file format is documented, the meaning of the field value will differ depending on the (update) release. With a new "dst" field, it's just another attribute that may or may not exist. If an updated version of 'jfr print" reads an older recording, it will default to dst being 0.