Add startTime and endTime in OffsetDateTime format

[doljae]

Motivation:

• We can check the start time and end time in the log for condition results.
• The unit of this start time and end time is milliseconds. This is a bit difficult to read from a user's point of view.

Modifications:

• Add startTime and endTime in OffsetDateTime format
• Add related methods, change variable names

Result:

• Now we can also see the start and end times in the logs in normal time notation instead of milliseconds.
• It is expected that the user will be able to check the information related to the start of the condition more intuitively.
• In ConditionMatchResult, you can check the OffsetDateTime type value similarly to the way you check the startTime and endTime.

Additional info:

• If startTime and endTime in milliseconds is the intended function please comment 🙂

[icepeppermint]

Thanks for the great suggestion! In my opinion, this method is not necessary. Because the conversion from milliseconds to OffsetDateTime doesn't have to be done here. Because developers using Conditional can do it themselves. What do you think of using the method below??

private static String millisAsISO8601String(long millis) {
    return Instant.ofEpochMilli(millis).atZone(ZoneId.systemDefault()).toOffsetDateTime().toString();
}

[doljae]

So, summarize your opinion...

1. ConditionMatchResult.startTimeMillis, ConditionMatchResult.endTimeMillis properties remain as long type as before.
2. ConditionMatchResult.toString() outputs startTime and endTime in OffsetDateTime format.

This seems like a good way. The values for startTime and endTime can be obtained through the public methods startTimeMillis() and endTimeMillis(), and We can know that the returned values are milliseconds through these method names, so users can return them as appropriate Date objects as needed 🙂

However, I think it is something to consider about the mismatch between the type provided in the log(OffsetDateTime) and the type actually provided(long).

Also, to use OffsetDateTime, the user must separately call the same method(you suggested) used to convert long to OffsetDateTime inside ConditionMatchResult.

So, if there's conversion from long to OffsetDateTime inside ConditionMatchResult.toString(), I think it's okay to add this value as a field and provide it for use as a public method.

What do you think?

[icepeppermint]

It seems we don't have to provide a public method to convert from Milliseconds -> OffsetDateTime. Because we need ZoneId or ZoneOffset to convert from Milliseconds to OffsetDateTime. Then, we need to receive ZoneId or ZoneOffset as parameter, which is no different from converting Milliseconds -> OffsetDateTime directly by the developer.

[doljae]

Thank you for your kind explanation.
As you said, it seems more reasonable to provide the millisecond information as before, and let the user use this to get the necessary Date object.

I'll fix on it based on what you commented on 🙂

[doljae]

I applied the way you suggested at 0fa5717 🙂

[icepeppermint]

If startTime and endTime are displayed in ISO-8601 format, it would be good to remove startTimeMillis and endTimeMillis.

[doljae]

Same as #9 (comment)

[icepeppermint]

Great work! Thank you for your contribution!