You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instant is a more ideomatic way of representing times in java (akin to unix time). It's a timezone-less entity (ie, UTC).
There are a bunch of helper functions to do any conversions you may want, as well as to/from ISO-8601 zulu-time strings.
ZonedDateTime contains timezone information, which (whilst useful) can introduce confusion when dealing with distributed systems. Ideally, all backend/server code (ie, Java) would use Instant (ie, fancy-formatted unix time) for all datetime representations, then leave it up to the frontend to worry about formatting with specific timezones.
I'm in agreement with this suggestion, though we also had a brief discussion on whether or not we wanted to include timestamps as "first class" data in the context or structure return values at all.
I think I'd like to keep timestamps as a first class type in the context, but I'm interested if others think it's worth the burden.
Instant
is a more ideomatic way of representing times in java (akin to unix time). It's a timezone-less entity (ie, UTC).There are a bunch of helper functions to do any conversions you may want, as well as to/from ISO-8601 zulu-time strings.
ZonedDateTime contains timezone information, which (whilst useful) can introduce confusion when dealing with distributed systems. Ideally, all backend/server code (ie, Java) would use
Instant
(ie, fancy-formatted unix time) for all datetime representations, then leave it up to the frontend to worry about formatting with specific timezones.I think it's worth changing https://github.com/open-feature/java-sdk/blob/main/src/main/java/dev/openfeature/javasdk/Value.java#L49-L51 to be using
Instant
instead ofZonedDateTime
The text was updated successfully, but these errors were encountered: