Ready for review.

Thanks for the review!

With regard toopening/closing_hours utilzing pythondatetime, A hurdle would be thatdatetime.datetime anddatetime.date typically expect a specific day in month while a business having an opening in (e.g.) Monday at 9 am would mean any Monday regardless of the month/week.
I also thoughtdatetime.time, which can be an improvement except that we also lose context of which day [Sat, Mon, ...] this opening/closing belongs to.

Finally, we could make a utilityBusinessOpeningHoursInterval.parse_hour that works like this

(day,hour,minute)=parse_hour(opening/closing_hours)# where day in [0, 1, .., 6]# hour in [0, 1, .., 24],# minute in [0, 1, .., 60]

But also users can calculate it themselves, since it's simple math operations.
what do you think?

I just tested what values are returned by the API and it's clear that those times are representing the minute of the week. Here's the results:

Monday - 00:00 - 01:05: BusinessOpeningHoursInterval(closing_minute=65, opening_minute=0)Monday - 08:00 - 20:00: BusinessOpeningHoursInterval(closing_minute=1200, opening_minute=480)Tuesday - 24 hours: BusinessOpeningHoursInterval(closing_minute=2879, opening_minute=1440)Thursday - 11:30 - 20:00: BusinessOpeningHoursInterval(closing_minute=5520, opening_minute=5010)Sunday - 00:00 - 23:58: BusinessOpeningHoursInterval(closing_minute=10078, opening_minute=8640)

I'll update the doc to further explain how those numbers are achieved.

Now the utility function - I like your idea but we can split it into two different properties -opening_time andclosing_time which do return that tuple of int's representing day, hour, and minute. This means that the user won't need to supply any input parameters.

We can also go one step further and overrideBusinessOpeningHoursInterval.__str__ and provide a friendly representation which returns e.g.Monday: 8am - 8pm. Thus a user can easily iterate overBusinessOpeningHours.opening_hours and justprint() it to see the values.

Another idea - (this may be a little out of scope) - We can have another function

BusinessOpeningHours.convert_to_timezone(timezone:datetime.tzinfo)->BusinessOpeningHoursInterval

Advantage is that its easier to schedule jobs and reduces potential errors.

cc@Bibo-Joshi

@aelkheir so@Bibo-Joshi and I discussed internally and decided to not pursueBusinessOpeningHoursInterval.__str__. As for the other two functions, you may complete them in this PR or choose to do it in another PR as it's not a priority. Let me know if you want to do them now, otherwise this PR is good to be merged.

not pursue BusinessOpeningHoursInterval.str.

Funnily enough i was just here to say that I don't know of a universal time representation that may fit all users, so we could let them use thetuple of ints and produce a representation to their liking.

I'll do it here and get it over with. But not untill tomorrow night hopefully :).

About the functionconvert_to_timezone, It turned out to be a but tricker, specifically becauseBusinessOpeningHoursInterval.{opening/closing}_minute could not not be represented as regular datetime/date/time.

A possibility i thought about was to get hours offset fromBusinessOpeningHour.time_zone_name toconvert_to_timezone.timezone and then do

BusinessOpeningHoursInterval(opening_minute=opening_minute+offset*60,closing_minute=closing_minute+offset*60)

with special handling to keep the minutes in the range0 - 10080

But this will require us to use pytz (?), and I see it's optional.
any thoughts@harshil21

Okay, I'm fine with waiting until we drop py 3.8 to implement these functions.

October (python 3.8 end of life) is not so far away. By then pytz could be droped entirely in favor of zoneinfo.

Thanks very much team for the opportunity <3

@aelkheir Thanks for the contribution!