Consider using `ChronoZonedDateTime`

[bsideup]

Currently, a concrete implementation (ZonedDateTime) is used, making it impossible to do lazy parsing.

If ChronoZonedDateTime (ZonedDateTime implements it) is used in the public API, it will provide the same set of useful APIs, but allow better flexibility.

[slinkydeveloper]

Uhm looking at the javadoc i see this: https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html

Most applications should declare method signatures, fields and variables as ZonedDateTime, not this interface.

[bsideup]

Yes. "Most" is the key.

[slinkydeveloper]

I think It would be wise to follow the official Javadoc.

[bsideup]

@slinkydeveloper care to explain?
Also, can we please keep the issue open until we have a consensus?

[olegz]

Yes, please reopen it. Closing legitimate issues before giving it due process and reasonable debate will eventually discourage community participation all together, which would be detrimental and quite frankly unfair to the entire Cloud Events and Cloud Native Computing Foundation effort, don't you think?

[slinkydeveloper]

I think the official javadocs are already pretty clear.

[slinkydeveloper]

But feel free to discuss about it

[bsideup]

@slinkydeveloper
The official javadoc only states that, in most places, you should prefer using ZonedDateTime.
That said, it does not say that you should never use the ChronoZonedDateTime interface.

It is a good practice, to use interfaces where available, because it allows more flexibility and does not force concrete implementation that may be costly to use (our case).

Unless you have good arguments why interface here would be bad, I don't think using the interface is hurting the library.

[olegz]

@slinkydeveloper javadoc also says:
. . .
A date-time with a time-zone in an arbitrary chronology, intended for advanced globalization use cases.

Unless I am mistaken, we are building a framework with hopes of global use and applicability, so by definition we can't treat it as most applications. So baking certain level of flexibility into the framework should be a default unless there is a strong argument against it - argument driven by a specific requirement.

[olegz]

Personally I would like to see a PR and then make a decision as I am sure a lot of the things will clear up with it.

[slinkydeveloper]

Because now we use OffsetDateTime, this issue is not valid anymore (OffsetDateTime doesn't extend ChronoZonedDateTime). Check out the release docs https://github.com/cloudevents/sdk-java/releases/tag/2.0.0-milestone2 and the pr #216 for more info