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

Implement addition and subtraction for Date_Period and Time_Period #6956

Merged
merged 17 commits into from
Jun 7, 2023

Conversation

GregoryTravis
Copy link
Contributor

@GregoryTravis GregoryTravis commented Jun 5, 2023

Pull Request Description

Date.+ should allow Date_Period, Time_Of_Day.+ should allow Time_Period and Date_TIme.+ should allow both.
Same for subtraction.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@GregoryTravis GregoryTravis marked this pull request as ready for review June 5, 2023 19:30
Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

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

Looks good overall, just some minor classification and one more test would be good.

I assume dropdown widgets don't work too well on +- operators, so we cannot control them, but could be worth checking.

Copy link
Member

@jdunkerley jdunkerley left a comment

Choose a reason for hiding this comment

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

Agree with @radeusgd comments - but lets also turn on the runtime type checking in a few places.

Comment on lines 508 to 511
- amount: The amount of time to add to this instant, either `Duration` for
adding time (hours, minutes, etc.), or `Period` for adding date (days,
months, years).
adding time (hours, minutes, etc.), `Period` for adding date (days,
months, years), or `Date_Period` for adding a single unit (year,
quarter, month, etc.).
Copy link
Member

Choose a reason for hiding this comment

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

Should have Time_Period as @radeusgd says. Probaly not "either" if 4 options.
Might be easier to just lose the stuff after this instant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How about just:

       - amount: The amount of time to add to this instant, It can be
         `Duration`, `Period`, `Date_Period`, or `Time_Period`.

test/Tests/src/Data/Time/Date_Time_Spec.enso Show resolved Hide resolved
@@ -430,8 +430,8 @@ type Date
Add the specified amount of time to this instant to get another date.

Arguments:
- amount: The time duration to add to this instant. Can only be a
`Period` or a `Date_Period`.
- amount: The amount of time to add to this instant. It can an be
Copy link
Member

Choose a reason for hiding this comment

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

There's something wrong with this sentence. Please fix wording.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, made the comments uniform.

+ : Period -> Date ! (Time_Error | Illegal_Argument)
+ self amount =
+ : Period | Date_Period -> Date ! (Time_Error | Illegal_Argument)
+ self amount:(Period|Date_Period) =
Copy link
Member

Choose a reason for hiding this comment

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

Personally I prefer

Suggested change
+ self amount:(Period|Date_Period) =
+ self (amount : Period|Date_Period) =

as IMO it looks nicer. But that is very subjective, feel free to ignore, just sharing my preferences :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jdunkerley what do you think?

@@ -370,6 +370,19 @@ spec_with name create_new_datetime parse_datetime nanoseconds_loss_in_precision=
time+Date_Period.Quarter-Date_Period.Month . should_equal <| create_new_datetime 1970 3 1 (zone = Time_Zone.utc)
time+Date_Period.Day-Time_Period.Day . should_equal <| create_new_datetime 1970 (zone = Time_Zone.utc)

Test.specify "should reflect that Time_Period.Day does not reflect daylight saving" <|
Copy link
Member

Choose a reason for hiding this comment

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

minor nitpick

Suggested change
Test.specify "should reflect that Time_Period.Day does not reflect daylight saving" <|
Test.specify "will reflect that Time_Period.Day does not reflect daylight saving" <|

for tests that show behaviour which is not necessarily what we desire but they document what is currently implemented, I tend to go for will instead of should; to distinguish such tests. IMO this gives us a bit more precision to what is the intended feature and what is more of an 'accidental' one

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@GregoryTravis GregoryTravis added the CI: Ready to merge This PR is eligible for automatic merge label Jun 7, 2023
@mergify mergify bot merged commit fcc57e4 into develop Jun 7, 2023
@mergify mergify bot deleted the wip/gmt/6930-date-math branch June 7, 2023 12:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants