Create a unified timestamp format

[chykon]

Description & Motivation

SystemVerilog and VCD will now use ISO 8601 UTC time when generating. Previously, local time was used, which could leak time zone information.

---

RENAMED: Use UTC and ISO 8601 for output -> Create a unified timestamp format

UPDATE: During the discussions, @mkorbel1 pointed out the need to preserve the human-readability of the format. The decision was made to leave the display of local time and add a UTC offset to it, which will correctly process timestamps from data coming from different time zones. Suggested timestamp format to use when generating SystemVerilog and VCD: YYYY-MM-DD hh:mm:ss.sss [+/-]hh:mm.

Related Issue(s)

No.

Testing

Ran tool/run_checks.sh, waited for successful completion. Ran example/example.dart, checked the output.

---

UPDATE: Added timestamp format test.

Backwards-compatibility

Is this a breaking change that will not be backwards-compatible? If yes, how so?

No.

---

UPDATE: Potentially yes. If someone was tied to the old time format, then he may suffer from a format change.

Documentation

Does the change require any updates to documentation? If so, where? Are they included?

No.

---

UPDATE: Yes. Documentation for the new utility class Timestamper. Included in PR.

[mkorbel1]

Previously, local time was used, which could leak time zone information.

When you say "leak", do you mean from a privacy/security perspective that sharing a file which was generated using ROHD could expose information about the person who generated it?

From a debuggability perspective, it seems convenient to not have to do timezone math to determine when you generated a file.

Is this a typical practice to always use UTC for generated timestamps? Please excuse my ignorance on the topic.

[chykon]

When you say "leak", do you mean from a privacy/security perspective that sharing a file which was generated using ROHD could expose information about the person who generated it?

Yes... although this may sound overly dramatic in the context of ROHD.

From a debuggability perspective, it seems convenient to not have to do timezone math to determine when you generated a file.

Yes, I mentioned the leak, but did not point out the advantages of a single point of reference for processing files. Oops.

Is this a typical practice to always use UTC for generated timestamps? Please excuse my ignorance on the topic.

It's hard to tell if this is a typical practice, but current timestamps use local time and don't preserve the time zone. If the data crosses time zones, then problems can arise in certain use cases. For example, someone sorts vcds received from all over the world by the $date field, which makes the sorting, with a high probability, actually wrong. Why he does this is another question.

[chykon]

It is possible to try to maintain both human convenience and processing accuracy. How about converting timestamps to the form local_time+utc_offset? For example, 1997-07-16T19:20:30.45+01:00.

[mkorbel1]

How about converting timestamps to the form local_time+utc_offset?

I think that's a great compromise, good idea!

[chykon]

Example:

• vcd

$date
  2023-02-18 17:19:12.260 +03:00
$end

• sv

/**
 * Generated by ROHD - www.github.com/intel/rohd
 * Generation time: 2023-02-18 17:19:12.150 +03:00
 * ROHD Version: 0.4.2
 */

[mkorbel1]

Looks great, thank you!