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

[#654] Get week start and end days #666

Merged
merged 4 commits into from Jun 15, 2022

Conversation

sestrella
Copy link
Contributor

@sestrella sestrella commented Mar 29, 2022

Thanks for contributing to chrono!

  • Have you added yourself and the change to the changelog? (Don't worry
    about adding the PR number)
  • If this pull request fixes a bug, does it add a test that verifies that
    we can't reintroduce it?

@djc
Copy link
Contributor

djc commented Mar 29, 2022

Thanks for working on this!

I think I suggested to make these NaiveDateTime instead of NaiveDate, are you still planning to change that?

src/naive/isoweek.rs Outdated Show resolved Hide resolved
@sestrella
Copy link
Contributor Author

Regarding:

I think I suggested to make these NaiveDateTime instead of NaiveDate, are you still planning to change that?

Sorry, I was about to leave a message explaining why I choose a NaiveDate over a NaiveDateTime. NaiveDateTime works well for the start_day and end_day functions, unfortunately, the week coming from bounds(Weekday) cannot be represented as a range of NaiveDateTime since there is no Step trait to create a Range<NaiveDateTime> and the internal iterator NaiveDateDaysIterator only works for NaiveDate. From the consumer standpoint, I think it would be useful if bounds(Weekday) returns something that could be treated as Range or Iterator (NaiveDateDaysIterator) in that sense NaiveDate might be a good choice for the start_day and end_day functions since they defined the bounds of the week for bounds(Weekday), I'm thinking about the following use cases:

  • Looping over the days in a week
  • Checking if a day is part of a week (this could be done via contains which is part of Range)

What do you think?

@djc
Copy link
Contributor

djc commented Mar 30, 2022

That makes sense to me, thanks for explaining your position in more detail!

@sestrella sestrella force-pushed the week_start_and_end_days branch 3 times, most recently from f76fa06 to 4c7e6df Compare April 22, 2022 02:19
@sestrella sestrella marked this pull request as ready for review April 22, 2022 02:19
@sestrella
Copy link
Contributor Author

@djc I think this PR is finally ready for a full review. Would you mind taking a look at it, please?

@sestrella
Copy link
Contributor Author

The implementation of start_day and end_day in the context of week vastly variate from the original proposal included in the issue, while most of the agreements made are document as comments, I'm more than happy to sum those up in order make it easier to review this PR. Please let me know if there is something I could do to facilitate the reviewing process. I deeply appreciate the time already invested in this PR

@sestrella sestrella force-pushed the week_start_and_end_days branch 2 times, most recently from 7ddf118 to 38fdb29 Compare May 5, 2022 21:44
@sestrella
Copy link
Contributor Author

The issue reported by the CI was fixed.

Copy link
Contributor

@djc djc left a comment

Choose a reason for hiding this comment

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

Sorry for the delay in reviewing this -- I was on holiday yesterday.

I think it mostly looks good, but I have some feedback to consider.

src/lib.rs Outdated
@@ -450,13 +448,15 @@ pub mod prelude {
#[doc(no_inline)]
pub use crate::SubsecRound;
#[doc(no_inline)]
pub use crate::{Date, Week};
Copy link
Contributor

@djc djc May 10, 2022

Choose a reason for hiding this comment

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

I don't think these need to be added to the prelude, since they're relatively niche.

src/traits.rs Outdated Show resolved Hide resolved
src/traits.rs Outdated
/// [start_day]: ./trait.Weeklike.html#tymethod.start_day
/// [end_day]: ./trait.Weeklike.html#method.end_day
#[inline]
fn range(&self) -> RangeInclusive<Self::Day> {
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 I'd prefer to call this days() to make it clear what the range's Item is. What do you think?

src/naive/date.rs Outdated Show resolved Hide resolved
#[derive(Debug)]
pub struct NaiveWeek {
date: NaiveDate,
weekday: Weekday,
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 weekday should be called start, as that is the intended role within the type (as far as I understand).


#[inline]
fn start_day(&self) -> Self::Day {
let start = self.date.weekday().num_days_from_monday() as i64;
Copy link
Contributor

Choose a reason for hiding this comment

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

We could calculate this in u8, right? Why are we casting here?

let start = self.date.weekday().num_days_from_monday() as i64;
let end = self.weekday.num_days_from_monday() as i64;
let days = start - end;
self.date - Duration::days(if days >= 0 { days } else { 7 + days })
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 if days >= 0 { days } else { 7 + days } could be more naturally expressed with some kind of modulo?

@sestrella sestrella force-pushed the week_start_and_end_days branch 2 times, most recently from 785dd1c to b274146 Compare May 17, 2022 05:17
@sestrella
Copy link
Contributor Author

sestrella commented May 27, 2022

@djc the latest commit seems to fix the CI issue, unfortunately the build is not getting trigger without an approval:

image

However, I tried it locally and it works:

image

src/date.rs Outdated
use crate::DateTime;
use crate::{Datelike, Weekday};

/// A week represented by a [`NaiveWeek`] + [Offset](crate::offset::Offset).
#[derive(Debug)]
pub struct Week<Tz: TimeZone> {
Copy link
Contributor

Choose a reason for hiding this comment

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

So, after reviewing some other PRs I'm on the fence about this concept of types that don't point to a specific time but do reference a timezone. Since the type represents a time span, the timezone offset could conceivably be different at the start of the span vs the end of the span, which we cannot represent accurately.

How important is having this type included to you? Could we make do with just the NaiveWeek?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@djc - It makes sense to me, starting with NaiveWeek sounds fair. I just updated the PR simplifying the implementation a little bit.

@sestrella sestrella force-pushed the week_start_and_end_days branch 2 times, most recently from 502df87 to 725e6d9 Compare June 9, 2022 16:40
@sestrella
Copy link
Contributor Author

sestrella commented Jun 9, 2022

Pushed a PR addressing the error reported by the linter:

> cargo fmt -- --check --color=always && echo "OK"
OK

@djc
Copy link
Contributor

djc commented Jun 13, 2022

Still some doc link issues, can you check that out?

sestrella and others added 4 commits June 15, 2022 00:31
Co-authored-by: David Mazarro <dmunuera@stackbuilders.com>
Co-authored-by: Jorge Guerra <jguerra@stackbuilders.com>
@sestrella
Copy link
Contributor Author

Hopefully, everything turns green this time 🤞🏼

> cargo +nightly doc && echo "OK"
OK

@djc djc merged commit 8dd7245 into chronotope:main Jun 15, 2022
@djc
Copy link
Contributor

djc commented Jun 15, 2022

Thanks for seeing this through!

@sestrella sestrella deleted the week_start_and_end_days branch June 15, 2022 13:39
@sestrella
Copy link
Contributor Author

Thank you for all the feedback and time spent on this PR

@DavidMazarro
Copy link
Contributor

Closes #654

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.

None yet

3 participants