New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[discovery] Refactor java.util.Date
usages to java.time.Instant
#4026
Conversation
Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
ead984c
to
6218ca6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. IMO the new formatting is even an improvement compression to the one before.
@@ -43,7 +43,7 @@ public class DiscoveryResultImpl implements DiscoveryResult { | |||
private @Nullable String representationProperty; | |||
private @NonNullByDefault({}) DiscoveryResultFlag flag; | |||
private @NonNullByDefault({}) String label; | |||
private long timestamp; | |||
private Instant timestamp = Instant.MIN; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@J-N-K - unfortunately I ran into this nasty regression today a moment ago:
2024-01-08 21:43:22.754 [ERROR] [re.storage.json.internal.JsonStorage] - Couldn't deserialize value 'org.openhab.core.storage.json.internal.StorageEntry@3df4a8fa'. Root cause is: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was NUMBER at path $.timestamp
so now realize that this object is deserialized from the JSON file userdata/org.openhab.core.config.discovery.DiscoveryResult.json
.
The easy solution is to revert this variable back to long
. Alternately we can keep Instant
, but implement custom deserialization that can handle both. WDYT? Right at this moment I'm not sure where this is deserialized.
Partially revert openhab#4026 Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk>
Write a converter for the JSON storage. |
Signed-off-by: Jacob Laursen <jacob-github@vindvejr.dk> Signed-off-by: Ciprian Pascu <contact@ciprianpascu.ro>
This refactors some java.util.Date usages to the more modern time API.
The API is preserved as epoch milliseconds, so this is a non-breaking change.
There is two user-facing changes, though.
Previously this would be displayed like this:
Since this is already quite technical, I didn't see a reason to invest in preserving the old formatting.
This is now UTC-formatted: