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

fix: change temporal add and subtract #337

Merged
merged 1 commit into from
Feb 23, 2023

Conversation

rok
Copy link
Contributor

@rok rok commented Sep 19, 2022

BREAKING CHANGE: change return type of temporal add and adds add/subtract with timezone.

@rok rok mentioned this pull request Sep 19, 2022
@jvanstraten
Copy link
Contributor

Just to be clear, the return type changes are merely fixes for rather obvious copy-paste mistakes, but are nevertheless breaking changes.

I failed to consider that the addition of the timezone argument is also a breaking change. Maybe that should be in yet another PR, just so we can be clearer about what the PRs actually change, i.e. something like "feat: add timezone argument to timezone_tz +/- interval_year function" and "fix: correct return types in datetime add function". I don't know if that's helpful or just adds clutter, though.

jvanstraten
jvanstraten previously approved these changes Sep 20, 2022
Copy link
Contributor

@jvanstraten jvanstraten left a comment

Choose a reason for hiding this comment

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

If we don't split this up this looks good to me, but requires an SMC vote according to the proposed governance document. @jacques-n @cpcloud @westonpace

@@ -104,6 +117,9 @@ scalar_functions:
value: timestamp_tz
- name: y
value: interval_year
- name: timezone
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 inclined to suggest that we just make a new variation that has timezone rather than change the existing here.

Copy link
Contributor

Choose a reason for hiding this comment

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

The reason we added it is because, as @rok noted, adding a month/year interval to an instant is ill-defined without timezone information. For example, an instant may be February 28th in one timezone and March 1st in another, so to add a month you'd have to add either 28 or 31 days.

That being said, we could still keep the original one with a note stating that it assumes UTC.

Copy link
Contributor

Choose a reason for hiding this comment

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

That being said, we could still keep the original one with a note stating that it assumes UTC.

Yes, that is what I was requesting.

Choose a reason for hiding this comment

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

If someone is adding 3 months to an instant, what makes you think that they want to do it in UTC? I don't think defaulting to UTC helps anyone.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the point is that removing the function is an unnecessary breaking change, and "3 months" is not well-defined without a local date, so it probably would have been interpreted as UTC. But heck, it's not even well-defined with a local date if the current day happens to be November 30.

IMO someone shouldn't be trying to add 3 months to an instant in the first place. It feels like adding an integer to a string and expecting concatenation. Just run the conversions explicitly.

Choose a reason for hiding this comment

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

@jvanstraten I pretty much agree. As you may know, I am one of these extremists who believes that instant, local time, and time-with-time-zone should be kept strictly separate, and therefore I would be inclined to remove the original method.

Copy link
Member

Choose a reason for hiding this comment

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

I'm inclined to agree with @julianhyde . I'd rather only add new functions and implementations when needed and not for the sake of convenience overloads (I also agree that the convenience here is rather dubious). Otherwise our set of functions gets unwieldy.

There will be a time when we are forced to leave functions around for deprecation reasons but I don't think we are there yet.

@jacques-n are you -1 on removing the old function? Or was that simply a recommendation?

extensions/functions_datetime.yaml Show resolved Hide resolved
extensions/functions_datetime.yaml Show resolved Hide resolved
@CLAassistant
Copy link

CLAassistant commented Oct 6, 2022

CLA assistant check
All committers have signed the CLA.

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@rok
Copy link
Contributor Author

rok commented Oct 18, 2022

Pushed the feedback suggestions and rebased. @jvanstraten

@rok rok force-pushed the change_temporal_add_subtract branch from 5d24096 to d82471f Compare October 19, 2022 10:16
@rok rok force-pushed the change_temporal_add_subtract branch 2 times, most recently from e896538 to 329004a Compare November 30, 2022 18:09
@rok rok force-pushed the change_temporal_add_subtract branch from 329004a to ac80d82 Compare January 14, 2023 01:02
@github-actions
Copy link

ACTION NEEDED

Substrait follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

@rok rok changed the title feat: change temporal add and subtract fix: change temporal add and subtract Jan 16, 2023
@rok rok requested review from jacques-n, julianhyde and jvanstraten and removed request for jacques-n and julianhyde January 16, 2023 16:05
@rok rok force-pushed the change_temporal_add_subtract branch from ac80d82 to 34d2300 Compare January 16, 2023 20:42
@rok rok force-pushed the change_temporal_add_subtract branch from 34d2300 to d823789 Compare February 13, 2023 10:22
@westonpace
Copy link
Member

Why is the timezone not required when adding a day? If a time zone has DST that might mean adding 23 or 25 hours correct?

@rok
Copy link
Contributor Author

rok commented Feb 16, 2023

Why is the timezone not required when adding a day? If a time zone has DST that might mean adding 23 or 25 hours correct?

Forgive me, it's been a while since I looked at this. I vaguely recall (and perhaps incorrectly) that the day interval is a calendrical unit as opposed to a physical one so want to subtract calendar days not physical units.

@rok rok force-pushed the change_temporal_add_subtract branch from d823789 to c7714d1 Compare February 16, 2023 15:57
@westonpace
Copy link
Member

Forgive me, it's been a while since I looked at this. I vaguely recall (and perhaps incorrectly) that the day interval is a calendrical unit as opposed to a physical one so want to subtract calendar days not physical units.

Hmm, refreshing my memory I do see this in the spec for interval_day:

Usually stored as separate integers for various components, but only the total number of microseconds is significant, i.e. 1d 0s is considered equal to 0d 86400s.

I suppose that means that we, indeed, do not need a time zone.

@@ -48,7 +53,11 @@ scalar_functions:
value: timestamp_tz
- name: y
value: interval_year
return: timestamp
- name: timezone
constant: true
Copy link
Member

Choose a reason for hiding this comment

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

Remove. Pending ML discussion on constant arguments in scalar functions.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed.

extensions/functions_datetime.yaml Outdated Show resolved Hide resolved
@rok rok force-pushed the change_temporal_add_subtract branch from c7714d1 to 634f8db Compare February 17, 2023 13:03
@rok
Copy link
Contributor Author

rok commented Feb 17, 2023

Thanks for the review @westonpace. I think I addressed all the points.

@rok rok force-pushed the change_temporal_add_subtract branch from 634f8db to 1e3e4d7 Compare February 17, 2023 17:53
@rok rok requested review from westonpace and removed request for jvanstraten February 17, 2023 19:10
@rok rok force-pushed the change_temporal_add_subtract branch from 1e3e4d7 to 080adfc Compare February 23, 2023 12:12
@westonpace
Copy link
Member

Thanks for figuring this out.

@westonpace westonpace merged commit 1b184cc into substrait-io:main Feb 23, 2023
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.

6 participants