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
Support rfc3339 micro-sec (6 digit) timestamp #1477
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -32,6 +32,9 @@ | |
import java.time.LocalDate; | ||
import java.time.OffsetDateTime; | ||
import java.time.format.DateTimeFormatter; | ||
import java.time.format.DateTimeFormatterBuilder; | ||
import java.time.format.DateTimeParseException; | ||
import java.time.temporal.ChronoField; | ||
import java.util.Date; | ||
import java.util.Map; | ||
import okio.ByteString; | ||
|
@@ -42,11 +45,22 @@ public class JSON { | |
|
||
private boolean isLenientOnJson = false; | ||
|
||
private static final DateTimeFormatter RFC3339MICRO_FORMATTER = | ||
new DateTimeFormatterBuilder() | ||
.parseDefaulting(ChronoField.OFFSET_SECONDS, 0) | ||
.append(DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss")) | ||
.optionalStart() | ||
.appendFraction(ChronoField.NANO_OF_SECOND, 6, 6, true) | ||
.optionalEnd() | ||
.appendLiteral("Z") | ||
.toFormatter(); | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure this is necessary. Why do we need an explicit formatter for a format that already works by default with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. kubernetes server-side requires 6-digit fraction for micro timestamp types (e.g. LeaseSpec#accquireTime) where "0" should be padded in the end if necessary. however, the default |
||
private DateTypeAdapter dateTypeAdapter = new DateTypeAdapter(); | ||
|
||
private SqlDateTypeAdapter sqlDateTypeAdapter = new SqlDateTypeAdapter(); | ||
|
||
private OffsetDateTimeTypeAdapter offsetDateTimeTypeAdapter = new OffsetDateTimeTypeAdapter(); | ||
private OffsetDateTimeTypeAdapter offsetDateTimeTypeAdapter = | ||
new OffsetDateTimeTypeAdapter(RFC3339MICRO_FORMATTER); | ||
|
||
private LocalDateTypeAdapter localDateTypeAdapter = new LocalDateTypeAdapter(); | ||
|
||
|
@@ -231,7 +245,12 @@ public OffsetDateTime read(JsonReader in) throws IOException { | |
if (date.endsWith("+0000")) { | ||
date = date.substring(0, date.length() - 5) + "Z"; | ||
} | ||
return OffsetDateTime.parse(date, formatter); | ||
try { | ||
return OffsetDateTime.parse(date, formatter); | ||
} catch (DateTimeParseException e) { | ||
// backward-compatibility for ISO8601 timestamp format | ||
return OffsetDateTime.parse(date, DateTimeFormatter.ISO_OFFSET_DATE_TIME); | ||
} | ||
} | ||
} | ||
} | ||
|
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.
This drops the milliseconds, right? Is that the intention? It also assumes that the timestamps are all UTC (but I think that is guaranteed by the k8s spec if they come from the server).
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.
yes, the leader-elector manages resource-locks w/ millis-sec timestamp, so it doesn't make a difference whether
LeaseLock
provides extra precision.