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

Updates Datum to use java.time for a sane datetime #1691

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Conversation

RCHowell
Copy link
Member

Description

This PR updates Datum to use java.time.

See #1654

Other Information

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

  • < If YES, which ones and why? >

  • < In addition, please also mention any other alternatives you've considered and the reason they've been discarded >

  • Do your changes comply with the Contributing Guidelines
    and Code Style Guidelines? [YES/NO]

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@RCHowell RCHowell changed the title Updates Datum to use java.time for a sane datetime. Updates Datum to use java.time for a sane datetime Dec 24, 2024
Copy link

github-actions bot commented Dec 24, 2024

CROSS-ENGINE-REPORT ❌

BASE (LEGACY-V0.14.8) TARGET (EVAL-BF3FE0F) +/-
% Passing 89.67% 94.32% 4.65% ✅
Passing 5287 5561 274 ✅
Failing 609 54 -555 ✅
Ignored 0 281 281 🔶
Total Tests 5896 5896 0 ✅

Testing Details

  • Base Commit: v0.14.8
  • Base Engine: LEGACY
  • Target Commit: bf3fe0f
  • Target Engine: EVAL

Result Details

  • ❌ REGRESSION DETECTED. See Now Failing/Ignored Tests. ❌
  • Passing in both: 2641
  • Failing in both: 17
  • Ignored in both: 0
  • PASSING in BASE but now FAILING in TARGET: 5
  • PASSING in BASE but now IGNORED in TARGET: 108
  • FAILING in BASE but now PASSING in TARGET: 180
  • IGNORED in BASE but now PASSING in TARGET: 0

Now FAILING Tests ❌

The following 5 test(s) were previously PASSING in BASE but are now FAILING in TARGET:

Click here to see
  1. undefinedUnqualifiedVariableWithUndefinedVariableBehaviorMissing, compileOption: PERMISSIVE
  2. undefinedUnqualifiedVariableIsNullExprWithUndefinedVariableBehaviorMissing, compileOption: PERMISSIVE
  3. undefinedUnqualifiedVariableIsMissingExprWithUndefinedVariableBehaviorMissing, compileOption: PERMISSIVE
  4. inPredicateWithTableConstructor, compileOption: PERMISSIVE
  5. notInPredicateWithTableConstructor, compileOption: PERMISSIVE

Now IGNORED Tests ❌

The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.

Now Passing Tests

180 test(s) were previously failing in BASE (LEGACY-V0.14.8) but now pass in TARGET (EVAL-BF3FE0F). Before merging, confirm they are intended to pass.

The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.

CROSS-COMMIT-REPORT ✅

BASE (EVAL-EA779EE) TARGET (EVAL-BF3FE0F) +/-
% Passing 94.32% 94.32% 0.00% ✅
Passing 5561 5561 0 ✅
Failing 54 54 0 ✅
Ignored 281 281 0 ✅
Total Tests 5896 5896 0 ✅

Testing Details

  • Base Commit: ea779ee
  • Base Engine: EVAL
  • Target Commit: bf3fe0f
  • Target Engine: EVAL

Result Details

  • Passing in both: 5561
  • Failing in both: 54
  • Ignored in both: 281
  • PASSING in BASE but now FAILING in TARGET: 0
  • PASSING in BASE but now IGNORED in TARGET: 0
  • FAILING in BASE but now PASSING in TARGET: 0
  • IGNORED in BASE but now PASSING in TARGET: 0


import java.math.BigDecimal;
import java.math.BigInteger;
import java.time.*;
Copy link
Member

Choose a reason for hiding this comment

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

nit: style-wise can use explicit imports

import org.jetbrains.annotations.NotNull;
import org.partiql.types.PType;
import org.partiql.value.datetime.Timestamp;

import java.time.*;
Copy link
Member

Choose a reason for hiding this comment

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

nit: similarly here, can use explicit imports

import org.jetbrains.annotations.NotNull;
import org.partiql.types.PType;

import java.time.*;
Copy link
Member

Choose a reason for hiding this comment

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

nit: explicit imports

val upper = args[2].time
val value = args[0].localTime
val lower = args[1].localTime
val upper = args[2].localTime
Copy link
Member

Choose a reason for hiding this comment

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

Seems like we're missing function definitions for timez and timestampz? Will those be added at some point? Similarly for the other builtin functions?

val now = TimestampWithTimeZone.nowZ()
Datum.timestamp(now)
val now = LocalDateTime.now()
Datum.timestamp(now, 6)
Copy link
Member

Choose a reason for hiding this comment

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

Should this be a timestamp or timestampz?

// calculate second/nanos
val ds = second.bigDecimal
val seconds: Int = ds.toInt()
val nanoOfSecond: Int = ds.remainder(BigDecimal.ONE).movePointRight(9).toInt()
Copy link
Member

Choose a reason for hiding this comment

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

nit: this is used in a few other places. perhaps could be some top-level variable/const?


@Test
@Disabled("The planner does not return the v1 plans right now. See assertExpression.") // TODO
fun testRandomDates() {
Copy link
Member

Choose a reason for hiding this comment

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

Why is this test getting removed?

@@ -736,18 +727,28 @@ static Datum blob(@NotNull byte[] value, int length) {
// DATE/TIME

@NotNull
static Datum date(@NotNull Date value) {
static Datum date(@NotNull LocalDate value) {
Copy link
Member

Choose a reason for hiding this comment

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

Perhaps I'm missing some context for the changes here. I had a couple questions

  1. Why are we opting to use the Java-defined datetime classes rather than the currently-defined datetime classes/interfaces in SPI? I'm not opposed but just would like some more context here.
  2. Will those datetime classes/interfaced defined in SPI be deleted at some point?

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