Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime #18335

georgeclaghorn · 2015-01-05T01:13:46Z

Per @dhh's request in #18330:

#weekend? returns true if the receiving date/time falls on a Saturday or Sunday.
#next_weekday returns a new date/time representing the next day that does not fall on a Saturday or Sunday.
#prev_weekday returns a new date/time representing the previous day that does not fall on a Saturday or Sunday.

Rails already provides #yesterday and #tomorrow for dates and times, so I didn't bother implementing #prev_day or #next_day.

dhh · 2015-01-05T01:36:41Z

The reason for prev_day and next_day is that they're more natural when the date you're working on isn't today. It doesn't make sense to talk about day_in_the_far_past.tomorrow. Tomorrow/yesterday are explicitly tied to today as the reference point.

dhh · 2015-01-05T01:39:10Z

Otherwise looking good! Although I'd also like to see #next_week same_time: true.

georgeclaghorn · 2015-01-05T02:24:09Z

@dhh: I added #next_day and #prev_day — took the path of least resistance and made them aliases for #yesterday and #tomorrow.

I'll take a look at adding the :same_time option tomorrow. Assuming we want that option for the other methods that drop times, too, like #prev_week, #beginning_of_week, and #end_of_week.

acutemedical · 2015-01-05T02:27:42Z

I'm loving these methods. Back in 3.2.x I wrote scopes that do just this.

dhh · 2015-01-05T02:33:37Z

@georgeclaghorn, I'd actually prefer to have them use advance(days: 1) and advance(days: -1). yesterday/tomorrow are just not clear for this purpose. Even if the result is the same, the code is a lot less clear.

I'd like same_time on prev_week, but I don't think it makes sense on beginning_of_week and end_of_week. Those are referring to a specific moment in time.

egilburg · 2015-01-05T05:58:37Z

If adding weekend?, a companion weekday? could make sense

egilburg · 2015-01-05T06:00:21Z

Cultural/regional implications could also be a concern. In some countries, for example, Friday is a weekend and/or Sunday isn't. Perhaps provide API like ActiveSupport.weekend_days = [6,0] (or ActiveSupport.weekend_days = [:saturday, :sunday] and let implementation use the DAYS_INTO_WEEK enum to map.

Extracting weekend_days into Active Support class var will also prevent new array creation on each call.

dhh · 2015-01-05T06:17:21Z

We define what workday and weekend means in the docs, so I'm ok with that.

Would have to be weekend_day? - not loving that.

On Jan 4, 2015, at 22:01, Eugene Gilburg notifications@github.com wrote:

Cultural/regional implications could also be a sight concern. In some countries, for example, Friday is a weekend and/or Sunday isn't.

—
Reply to this email directly or view it on GitHub.

georgeclaghorn · 2015-01-06T04:16:31Z

@dhh:

Deprecated #yesterday and #tomorrow in favor of #prev_day and #next_day.
Added same_time option to #prev_week and #next_week.

I kept this PR divided into three separate commits and CHANGELOG entries. I'm happy to squash them if you'd prefer, but they seemed like distinct sets of changes to me.

dhh · 2015-01-06T04:19:33Z

Sorry, I was not being clear :). I think #yesterday and #tomorrow still make sense when you're doing operations on stuff like Date#today. So don't think we need to deprecate them, but we do need prev_day and next_day doing essentially the same thing, so when you operate on not-today dates, it doesn't read odd.

dhh · 2015-01-06T04:21:49Z

Also, I prefer #on_a_weekend? over #weekend? – a weekend is the whole thing, sat + sun, so to me it doesn't make sense to ask whether a single day is THE weekend. It's on a weekend, but it's not the weekend by itself.

All good with different commits 👍

georgeclaghorn · 2015-01-06T04:22:00Z

No problem. Just to make sure I'm understanding correctly, you want #prev_day and #next_weekday to have the same implementations as #yesterday and #tomorrow instead of being aliases, correct?

dhh · 2015-01-06T04:23:39Z

Correct :). Because the implementation is already a sort of alias by using advance, and it's just clearer that way imo.

georgeclaghorn · 2015-01-06T10:40:47Z

@dhh: OK, think everything's good now.

…ime, and DateTime `#on_weekend?` returns true if the receiving date/time falls on a Saturday or Sunday. `#next_weekday` returns a new date/time representing the next day that does not fall on a Saturday or Sunday. `#prev_weekday` returns a new date/time representing the previous day that does not fall on a Saturday or Sunday.

… DateTime

…ow for Date, Time, and DateTime

kuldeepaggarwal · 2015-01-06T15:30:35Z

@dhh: yes, I agree that the weekend is the whole thing sat + sun, but here we just want to know whether today is sat or sun not both, as today can be either of them. So IMO weekend? should be more appropriate in this scenario.

Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime

dhh · 2015-01-06T16:50:06Z

Thanks @georgeclaghorn!

@kuldeepaggarwal I don't quite follow that argument. on_weekend is similar to the form of "[object] in? [set]".

kuldeepaggarwal · 2015-01-06T16:53:44Z

activesupport/lib/active_support/core_ext/date_and_time/calculations.rb

+    end
+
+    # Returns a new date/time representing the next day.
+    def next_day


@dhh: I think this might be an alias of tomorrow. wdyt?

It could have been, and @georgeclaghorn initially implemented it as such, but I find that more confusing. Clarity > DRY.

Great... 👍

donaic · 2015-01-10T02:09:02Z

What about is_business_day? and next_business_day

dhh · 2015-01-10T02:12:46Z

How would those differ from weekday?

On Jan 9, 2015, at 9:09 PM, donaic notifications@github.com wrote:

What about is_business_day? and next_business_day

—
Reply to this email directly or view it on GitHub #18335 (comment).

georgeclaghorn · 2015-01-10T02:14:21Z

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.

donaic · 2015-01-10T02:15:19Z

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.

dhh · 2015-01-10T02:16:36Z

Don’t think we need any aliases here.

On Jan 9, 2015, at 9:15 PM, George Claghorn notifications@github.com wrote:

I'm not opposed to weekday? as a complement to on_weekend?, but I don't think next_business_day is a necessary alias for next_weekday.

—
Reply to this email directly or view it on GitHub #18335 (comment).

dhh · 2015-01-10T02:17:11Z

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.

—
Reply to this email directly or view it on GitHub #18335 (comment).

acutemedical · 2015-01-10T04:12:46Z

I really love where this is going, I've written tons of scopes and methods that do similar back in 3.2.x. Would love to help.

On Jan 9, 2015, at 20:17, David Heinemeier Hansson notifications@github.com wrote:

Ah, I see. Yeah, I think that’s very country/company specific. I don’t think that’d be a good fit for core, but could make an interesting plugin.

On Jan 9, 2015, at 9:16 PM, donaic notifications@github.com wrote:

Holidays are not business day. This may be too country specific to be useful, but thought it would be worth a discussion. Could have default holidays that can be modified as necessary.

—
Reply to this email directly or view it on GitHub #18335 (comment).

—
Reply to this email directly or view it on GitHub.

shireeshj · 2015-01-10T10:03:31Z

Many countries follow different work week. Assuming Saturday+Sunday could be limiting the scope.
For example Isreal, UAE etc. see wikipedia

donaic · 2015-01-10T13:56:25Z

What about is_monday? etc...

georgeclaghorn · 2015-01-10T14:27:47Z

@donaic: Ruby core has that covered with #monday?, #tuesday?, etc.

ecleel · 2015-01-11T10:12:38Z

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.

dhh · 2015-01-11T15:31:58Z

It's more work to add and set a config than just overwriting this method in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com wrote:

I agree with @egilburg we need a way to change a #weekend? days from the default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now is Friday and Saturday.

Perhaps if we can use locale files to do that.

—
Reply to this email directly or view it on GitHub.

guilleiguaran · 2015-01-11T17:17:02Z

+1 for overwriting in this case

On Sun, Jan 11, 2015 at 10:32 AM, David Heinemeier Hansson <
notifications@github.com> wrote:

It's more work to add and set a config than just overwriting this method
in your local app.

On Jan 11, 2015, at 02:13, Abdulaziz AlShetwi notifications@github.com
wrote:

I agree with @egilburg we need a way to change a #weekend? days from the
default [Sat and Sun] to country specific, e.g. in Saudi Arabia weekend now
is Friday and Saturday.

Perhaps if we can use locale files to do that.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#18335 (comment).

egilburg · 2015-01-11T18:21:47Z

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.

dhh · 2015-01-11T18:31:55Z

A config option would have the same effect as overwriting the method will.

On Jan 11, 2015, at 10:22 AM, Eugene Gilburg notifications@github.com wrote:

API implies Rails supports this as a feature, and will ensure that whatever code is built upon this later will remain working when the API is used. Developers overwriting core extensions means they entering "hacker territory" and are on their own in dealing with whatever consequences bubble up as a result.

That being said, I concede it's not currently a pragmatic difference in this particular part of the code.

—
Reply to this email directly or view it on GitHub #18335 (comment).

shireeshj · 2015-01-14T05:32:50Z

I agree with @egilburg. It is kind of natural to expect a core extension to be "complete", especially something that has got to do with date and time (because the rules for these are well defined and understood, as opposed to say, strings).

johnnyshields · 2015-01-17T11:35:30Z

FYI we have a lot of this stuff in the ByStar gem (https://github.com/radar/by_star).

vipulnsward · 2016-02-14T19:17:44Z

@dhh wdyt about having on_weekday?, compliment on_weekend? here?

PS: Would also love to hear your thoughts on prev to previous. Having short prefix prev scattered everywhere can be a bit confusing.

dhh · 2016-02-15T10:06:14Z

Fine with adding on_weekday? to complete the set. Not sure I understand the question re: prev? It doesn't stand alone, it goes with prev_workday.

vipulnsward · 2016-02-15T12:53:27Z

So the question was about using previous, instead of prev, like previous_weekday, etc. We usually don't use short names on methods.
I see that we have been using methods like prev_month, prev_year before, so this is ok I guess.

dhh · 2016-02-15T13:07:31Z

Ah, yes. Following prior pattern as well as the concern that this is a method you'd frequently want to type on say a console.

senny added this to the 5.0.0 milestone Jan 5, 2015

senny added the activesupport label Jan 5, 2015

georgeclaghorn added 3 commits January 6, 2015 05:42

Add same_time option to #prev_week and #next_week for Date, Time, and…

b6d0d0d

… DateTime

Add #prev_day and #next_day as counterparts to #yesterday and #tomorr…

4c53f58

…ow for Date, Time, and DateTime

dhh added a commit that referenced this pull request Jan 6, 2015

Merge pull request #18335 from georgeclaghorn/day-gymnastics

0d28543

Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime

dhh merged commit 0d28543 into rails:master Jan 6, 2015

kuldeepaggarwal reviewed Jan 6, 2015
View reviewed changes

georgeclaghorn deleted the day-gymnastics branch January 6, 2015 17:06

rafaelfranca modified the milestones: 5.0.0 [temp], 5.0.0 Dec 30, 2015

vipulnsward mentioned this pull request Feb 15, 2016

Add #on_weekday? method to Date, Time, and DateTime. #23687

Merged

mpscholten mentioned this pull request Oct 3, 2021

isWeekend is country specific digitallyinduced/ihp#1100

Closed

Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime #18335

Add #weekend?, #next_weekday, and #prev_weekday methods to Date, Time, and DateTime #18335

Conversation

georgeclaghorn commented Jan 5, 2015

dhh commented Jan 5, 2015

dhh commented Jan 5, 2015

georgeclaghorn commented Jan 5, 2015

acutemedical commented Jan 5, 2015

dhh commented Jan 5, 2015

egilburg commented Jan 5, 2015

egilburg commented Jan 5, 2015

dhh commented Jan 5, 2015

georgeclaghorn commented Jan 6, 2015

dhh commented Jan 6, 2015

dhh commented Jan 6, 2015

georgeclaghorn commented Jan 6, 2015

dhh commented Jan 6, 2015

georgeclaghorn commented Jan 6, 2015

kuldeepaggarwal commented Jan 6, 2015

dhh commented Jan 6, 2015

kuldeepaggarwal Jan 6, 2015

Choose a reason for hiding this comment

dhh Jan 6, 2015

Choose a reason for hiding this comment

kuldeepaggarwal Jan 6, 2015

Choose a reason for hiding this comment

donaic commented Jan 10, 2015

dhh commented Jan 10, 2015

georgeclaghorn commented Jan 10, 2015

donaic commented Jan 10, 2015

dhh commented Jan 10, 2015

dhh commented Jan 10, 2015

acutemedical commented Jan 10, 2015

shireeshj commented Jan 10, 2015

donaic commented Jan 10, 2015

georgeclaghorn commented Jan 10, 2015

ecleel commented Jan 11, 2015

dhh commented Jan 11, 2015

guilleiguaran commented Jan 11, 2015

egilburg commented Jan 11, 2015

dhh commented Jan 11, 2015

shireeshj commented Jan 14, 2015

johnnyshields commented Jan 17, 2015

vipulnsward commented Feb 14, 2016

dhh commented Feb 15, 2016

vipulnsward commented Feb 15, 2016

dhh commented Feb 15, 2016