Skip to content
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

Feature/add iso 8601 timestamp serialization #308

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

tisla1080
Copy link
Contributor

Currently ISO-8601 can't be serialized with the existing date time formatters when creating a LocalDateTIme object. Additionally, the LocalDateTime object does not capture the current time in UTC which can lead to discrepancies across servers. To avoid this issue, we can use the Instant class.

This class captures a timezone in ISO-8601 format (yyyy-MM-dd'T'HH:mm:ss.SSSSSSSSS'Z'). There are 2 variations on the input:

  • including 'Z' at the end to denote the timestamp is already representing UTC. ex: 2023-10-06T15:50Z
  • including the +/-HH:mm offset at the end to have it automatically convert into UTC using the offset 2023-10-06T15:50+02:00 will convert to 2023-10-06T13:50Z

To enable this behavior, a custom serializer / deserializer is added to allow optional seconds. By default the seconds are not optional, only the milliseconds are.

@tisla1080 tisla1080 requested a review from a team as a code owner August 8, 2024 17:00
Copy link
Contributor

@jmartinez5120 jmartinez5120 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check my comments.

.append(DateTimeFormatter.ISO_LOCAL_TIME)
.appendLiteral('Z')
.toFormatter()
.withZone(ZoneOffset.UTC);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we set the Zone, do we need to append the Literal Z?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we do otherwise, we end up getting the string back as "2024-08-30T14:48:34.857239" even though the java Instant object value was actually 2024-08-30T14:48:34.857239Z. The numbers all look correct but we miss the Z if we remove the appendLiteral. If we remove the withZone then we get a parsing error entirely

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants