Forbid trappy methods from java.time #28476
Conversation
DaveCTurner
added
the
:Data Management/Ingest Node
| } else if (value instanceof ZonedDateTime) { | ||
| ZonedDateTime zonedDateTime = (ZonedDateTime) value; | ||
| return ZonedDateTime.of(zonedDateTime.toLocalDate(), zonedDateTime.toLocalTime(), zonedDateTime.getZone()); | ||
| return ZonedDateTime.ofInstant(zonedDateTime.toLocalDateTime(), zonedDateTime.getOffset(), zonedDateTime.getZone()); |
There was a problem hiding this comment.
TBH I'm wondering whether this could just use zonedDateTime directly, since it is supposed to have value semantics. Put differently, why not also deep-copy the LocalDateTime and ZoneId and so on?
There was a problem hiding this comment.
I'm not sure I understand. does it matter?
There was a problem hiding this comment.
It does but I should have added a test to show this. It only very rarely matters, which is why it's trappy. I added a test.
There was a problem hiding this comment.
Hmm, ok, I forgot I'd made that original comment, but I think I was answering a different question in my previous reply.
The question is why not simply this:
else if (value instanceof ZonedDateTime) {
return value;I thought this would be ok because ZonedDateTime is immutable and we shouldn't be looking at reference equality on it. If that's not fine, because we do want the contents of the copy to share no references with the original for some reason, then what we do here doesn't do that since it makes a shallow copy of the ZonedDateTime, because it copies the LocalDateTime instance within.
talevy
left a comment
talevy
left a comment
There was a problem hiding this comment.
LGTM.
thanks for looking at this, I'm not entirely sure about the repercussions of your code comment, but the current changes look reasonable enough?
spinscale
left a comment
spinscale
left a comment
There was a problem hiding this comment.
LGTM, thanks for doing that! Just returning the ZonedDateTime looks good to me as well, but I might be missing why it was added in the first place (didnt check history)
|
Ok, there was already a case for value types like |
ava.time has the functionality needed to deal with timezones with varying offsets correctly, but it also has a bunch of methods that silently let you forget about the hard cases, which raises the risk that we'll quietly do the wrong thing at some point in the future. This change adds the trappy methods to the list of forbidden methods to try and help stop this from happening. It also fixes the only use of these methods in the codebase so far: IngestDocument#deepCopy() used ZonedDateTime.of() which may alter the offset of the given time in cases where the offset is ambiguous.
5 participants
java.timehas the functionality needed to deal with timezones with varying offsets correctly, but it also has a bunch of methods that silently let you forget about the hard cases, which raises the risk that we'll quietly do the wrong thing at some point in the future.This change adds (what I think to be) the trappy methods to the list of forbidden methods to try and help stop this from happening.
There was only one use of these methods in the codebase so far:
IngestDocument#deepCopy()usedZonedDateTime.of()which may alter the offset of the given time in cases where the offset is ambiguous.