On 7/11/2018 10:17 AM, Charles Mills wrote:
You're right of course. I still stand by my assertion that most of the formats are stupid, and the standard SMF format is no prize-winner. Milliseconds (or even microseconds) since the start of some era would have fit conveniently in 64 bits, would have given one more digit of precision, would have made interval calculations trivial, would have put off partial conversion to a civil format from real-time to report-time, and would not have wrapped until well after we are all retired.
One of the objectives of the EasySMF Java SMF mapping is to provide all times as standard java.time values.
Durations e.g. CPU time are available as both a java.time.Duration and a double with the value in seconds.
Times are provided as different types based on what they contain, e.g. java.time.LocalDateTime for times in local time, java.time.ZonedDateTime with ZoneOffset.UTC for UTC values.
This means that (if your system follows the rules for DST changes) you can apply a timezone to local time values and use the built in Java time zone rules to compare with UTC times, or even match times between 2 systems with different time zones.
e.g. https://static.blackhillsoftware.com/easysmf/javadoc/com/blackhillsoftware/smf/smf30/Smf30Record.html -- Andrew Rowley Black Hill Software ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
