Closed c960657 closed 4 years ago
Thank you very much for this! It is indeed not correct that isWorkingDay
always returns true :(.
When I started with this library, I was already aware that the current types/categories wouldn't be sufficient or cover all situations. The current implementation is simple and would cover the majority of scenarios.
That said, I really like your proposal. Of course when introducing additional data, appropriate helper methods (API) should be present as well. To make it easier for people to use.
This illustrates what I had in mind: https://github.com/azuyalabs/yasumi/compare/develop...c960657:holiday-tags
I may have gone a bit overboard. On the other hand, as long as the tags are reasonably well-defined, it doesn't take a lot of work for a person with knowledge about a given country to add the relevant tags.
I have tried to think of tags for a variety of reasons, but I have probably missed some. In particular, my knowledge about non-Western cultures is very limited.
The syntax for adding all these tags feels a bit clunky. I guess this is a necessary evil.
What do you think?
Thanks for the suggestion! I think the idea is really good. I need to have a little bit more thought about it. Nonetheless I think this could be very beneficial.
A different approach would be to have specific providers for different use-cases. E.g. Yasumi\Provider\Denmark\SchoolHolidays
, OfficeHolidays
, BankHolidays
.
Possibly with provider-specific holiday types, e.g. for Yasumi\Provider\India\ReligousHolidays
, type could be TYPE_CHRISTIAN
, TYPE_BUDDHIST
etc.
Such providers may be easier to implement, because they each have a more specific scope.
The implementation may indeed be more simpler, however the current way feels a bit more natural to me. It simply communicates: 'What are all the holidays in India?', irrespective of the classification.
Creating classes that encompass a specific scope would require a developer to make (coding) decision what class to use.
Maybe not a strong argument, but just my initial feeling :) I would prefer the initial proposal rather.
This issue has been open 60 days with no activity. Please remove the stale label or comment, or this will be closed in 10 days.
I would like to help with this. If someone adds the tags, I will go through USA holidays and add proper tag to the each one.
@siburny Thank you for willing to help. Unfortunately this feature is not at the stage where there is a conclusive design nor even a proof of concept. This still needs to be vetted out.
I think this idea of "tags" is spot on. Each holiday date can be assigned one or more tags. However, I do think we should avoid mixing "types" and "tags"; we should stick to one classification system.
Working days
AbstractProvider::isWorkingDay()
returns true for any defined holiday, including e.g. Valentines Day. This is surprising. I belive Valentines Day is a working day for everyone, even the most romantically inclined :-)I guess all
TYPE_OFFICIAL
holidays are official non-workdays. But there are also some holidaysTYPE_OBSERVANCE
holidays that are de-facto non-workdays, at least for some companies/public offices.For a large number of use-cases for showing holidays in business software, the only holidays of interest are those that affect the business, i.e. when other businesses (banks in particular) are closed. And not so much when people buy flowers to their sweethearts :-)
I know that “working day” is not a boolean property. But I think holidays can be tagged with different fairly objective properties that allow users to get a list of holidays that are relevant for a specific purpose.
Other use-cases include listing all bank holidays or holidays where shops are closed.
I suggest adding a new attribute in addition to the current
TYPE_xxx
property. This should be a bitmask or tag list that allows multiple flags/tags per holiday.Currently a holiday can only have one type, so if a holiday is both a public holiday and a bank holiday, it can only be classified as one of them. This means that you cannot get a list of all bank holidays.
The list of flags could look something like this:
The exact meaning of the words “all” and “significant” should be defined more clearly, e.g. >95% and >30%, respectively.
What do you think of adding such extra data?