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

feat(connect): add temporal functions #3799

Merged

Conversation

universalmind303
Copy link
Contributor

No description provided.

@github-actions github-actions bot added the feat label Feb 12, 2025
Copy link

codecov bot commented Feb 12, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 76.61%. Comparing base (ca36593) to head (59cc990).
Report is 1 commits behind head on main.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #3799      +/-   ##
==========================================
- Coverage   77.82%   76.61%   -1.21%     
==========================================
  Files         745      746       +1     
  Lines       94416    98721    +4305     
==========================================
+ Hits        73480    75636    +2156     
- Misses      20936    23085    +2149     
Files with missing lines Coverage Δ
src/daft-connect/src/functions.rs 62.96% <100.00%> (+0.69%) ⬆️
src/daft-connect/src/functions/core.rs 72.50% <100.00%> (-0.34%) ⬇️
src/daft-connect/src/functions/datetime.rs 100.00% <100.00%> (ø)
src/daft-connect/src/functions/math.rs 56.89% <100.00%> (ø)
.../daft-connect/src/functions/partition_transform.rs 28.00% <ø> (ø)
src/daft-connect/src/functions/string.rs 60.00% <100.00%> (ø)

... and 26 files with indirect coverage changes

Comment on lines +56 to +60
parent.add_fn("to_date", UnaryFunction(|arg| arg.cast(&DataType::Date)));
parent.add_fn(
"to_timestamp",
UnaryFunction(|arg| arg.cast(&DataType::Timestamp(TimeUnit::Milliseconds, None))),
);
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm curious if the semantics of our cast are actually the same, cast rules are rightfully prescriptive but we/spark could do anything with a to_type function. No need to update here – am mostly curious if these accurate.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah, I'm not entirely sure if this is correct (according to spark). AFAIK, most to_timestamp methods use milliseconds as the default, and i couldn't find anything in the spark docs saying otherwise

@universalmind303 universalmind303 merged commit 8f10933 into Eventual-Inc:main Feb 12, 2025
38 of 40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants