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
ZonedDateTime instances are not equal to other ZonedDateTime instances with different time zones, and so when we do convert to a long for hashing or sorting we are changing the definition of equals that applies.
Our "automatic" conversion code in ReinterpretUtils.maybeConvertToPrimitive rightlfully requires support for symmetric conversion from the ColumnSource to be reinterpreted (i.e. source instanceof ConvertibleTimeSource.Zoned) and thus a single time zone for the entire ColumnSource.
Secondly, the consistency issues:
naturalJoin and join are never reinterpreting ZonedDateTime key sources to long for hashing. Hence they are always applying ZonedDateTime.hashCode() and ZonedDateTime.equals(). This is internally consistent within the operations, at least, but inconsistent with other operationsaj.
aj is using ReinterpretUtils.maybeConvertToPrimitive, and so we might reinterpret only one side, resulting in an error that seems inexplicable to users. We will also be getting equality "wrong" (by the Java definition) if the two sides have different time zones.
aggBy converts symmetrically, which is good. However, it is effectively picking different definitions of equality depending on the provenance of the ZonedDateTime key source. With current maybeConvertToPrimitive, we're always correct.
sort has basically the same issue as aggBy. While we're always using a comparison that is consistent with equality, which definition of comparison and equality we use depends on the source. With current maybeConvertToPrimitive, we're always correct.
Solutions:
Remove ZonedDateTime support from maybeConvertToPrimitive. This standardizes on Java's definition of comparison and equality, but eliminates opportunities for optimization.
Remove the restriction that we only convert to primitive when reversible. This requires extra work to figure out what our result time zone should be in many cases. If we have a join with mismatched ConvertibleTimeSource.Zoned.getZone() results, we need to error out or "pick a winner". Worse, if we have to convert back from an un-zoned long source, we need to pick a zone. DateTimeUtils.timeZone(), e.g. the system default?
Keep maybeConvertToPrimitive the same. For joins, we should only convert if both sides are reinterpretable and have the same fixed zone.
I think we should pick option (2), as that renders it less fraught to reinterpret between Instant and ZonedDateTime. Otherwise, this reinterpretation changes the meaning of equality, etc, for the data within the column.
I think we should pick option (3). It means zone matters for equality and comparison. It keeps aggBy and sort correct with current optimizations. We could eventually optimize naturalJoin and join, but they are correct as-is. We would have to fix a bug in aj that might result in error messages or incorrect equality/comparability.
The text was updated successfully, but these errors were encountered:
Firstly, the over-arching issues:
ZonedDateTime
instances are not equal to otherZonedDateTime
instances with different time zones, and so when we do convert to along
for hashing or sorting we are changing the definition of equals that applies.ReinterpretUtils.maybeConvertToPrimitive
rightlfully requires support for symmetric conversion from theColumnSource
to be reinterpreted (i.e.source instanceof ConvertibleTimeSource.Zoned
) and thus a single time zone for the entireColumnSource
.Secondly, the consistency issues:
naturalJoin
andjoin
are never reinterpretingZonedDateTime
key sources tolong
for hashing. Hence they are always applyingZonedDateTime.hashCode()
andZonedDateTime.equals()
. This is internally consistent within the operations, at least, but inconsistent withother operationsaj
.aj
is usingReinterpretUtils.maybeConvertToPrimitive
, and so we might reinterpret only one side, resulting in an error that seems inexplicable to users. We will also be getting equality "wrong" (by the Java definition) if the two sides have different time zones.aggBy
converts symmetrically, which is good.However, it is effectively picking different definitions of equality depending on the provenance of theWith currentZonedDateTime
key source.maybeConvertToPrimitive
, we're always correct.sort
has basically the same issue asaggBy
.While we're always using a comparison that is consistent with equality, which definition of comparison and equality we use depends on the source.With currentmaybeConvertToPrimitive
, we're always correct.Solutions:
ZonedDateTime
support frommaybeConvertToPrimitive
. This standardizes on Java's definition of comparison and equality, but eliminates opportunities for optimization.ConvertibleTimeSource.Zoned.getZone()
results, we need to error out or "pick a winner". Worse, if we have to convert back from an un-zonedlong
source, we need to pick a zone.DateTimeUtils.timeZone()
, e.g. the system default?maybeConvertToPrimitive
the same. For joins, we should only convert if both sides are reinterpretable and have the same fixed zone.I think we should pick option (2), as that renders it less fraught to reinterpret betweenInstant
andZonedDateTime
. Otherwise, this reinterpretation changes the meaning of equality, etc, for the data within the column.I think we should pick option (3). It means zone matters for equality and comparison. It keeps
aggBy
andsort
correct with current optimizations. We could eventually optimizenaturalJoin
andjoin
, but they are correct as-is. We would have to fix a bug inaj
that might result in error messages or incorrect equality/comparability.The text was updated successfully, but these errors were encountered: