-
Notifications
You must be signed in to change notification settings - Fork 156
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
fix: change temporal add and subtract #337
Conversation
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. |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
|
36f4950
to
154d027
Compare
Pushed the feedback suggestions and rebased. @jvanstraten |
5d24096
to
d82471f
Compare
e896538
to
329004a
Compare
329004a
to
ac80d82
Compare
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. |
ac80d82
to
34d2300
Compare
34d2300
to
d823789
Compare
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. |
d823789
to
c7714d1
Compare
Hmm, refreshing my memory I do see this in the spec for interval_day:
I suppose that means that we, indeed, do not need a time zone. |
extensions/functions_datetime.yaml
Outdated
@@ -48,7 +53,11 @@ scalar_functions: | |||
value: timestamp_tz | |||
- name: y | |||
value: interval_year | |||
return: timestamp | |||
- name: timezone | |||
constant: true |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed.
c7714d1
to
634f8db
Compare
Thanks for the review @westonpace. I think I addressed all the points. |
634f8db
to
1e3e4d7
Compare
1e3e4d7
to
080adfc
Compare
Thanks for figuring this out. |
BREAKING CHANGE: change return type of temporal
add
and addsadd/subtract
withtimezone
.