Exactly. Couldn’t have said it better.
IMHO this is a case which is already handled by simply not specifying PH, then everything works (you could always include that as a remark in a comment to avoid the stipulated confusion by human parsers of an OH string).
In general as said at the beginning, in the case of completely unchanged OH on public holidays, nothing needs to be done. Changing the grammar is unlikely to be backwards compatible and as a consequence going to be very expensive (and not funded by validator operators).
Seems like I’ve started quite a debate!
My main problem with “just don’t specify an PH if it is the same” is indeed that it is not explicit. One cannot know if the mapper knows about the PH status or simply did not add it.
Examples like “Mo-Fr, PH 10:00-18:00” indeed have the problem that this means “if a public holiday is on a saturday/sunday, the venue is open 10:00-18:00”. The other proposals “Mo-Fr, PH 10:00-18:00; Sa-su off” somewhat work, but indeed complicate matters more and still suffer from duplication. E.g something `mo, PH 10:00-12:00, tu, PH 12:00-14:00; we, PH 14:00-16:00` would also need to specify all the off-times explicitly too, so I don’t really see this as a solution. I see this mostly as a mapping simplification - the character limit is less of a reason.
The argument “changing the syntax means we will have to update all the validators” holds some ground, but is a “tagging for the renderer”-argument in disguise. Yes, this will be a lot of work, yes this’ll take years; but [ypid from openinghours.js is at least not against this idea]( Proposal: `PH as usual` (and `SH as usual`) · Issue #631 · opening-hours/opening_hours.js · GitHub ). However, `PH as usual` can simply be omitted by the parsers so it should be a relatively simple change.
I don’t have a strong opinion about the specific phrase (“PH as usual”, “PH open as usual”, “PH unchanged”, …) as long as it intuitively clear to most mappers (which eliminates “PH unobserved” which was beautifully refuted earlier on by alan_gr).
A tag indicating that PH hours are not advertised publicly can be useful too, but I don’t want to focus on this here and now. For the sake of this discussion, I’m assuming that PH-hours are clearly indicated.
2 Likes
All the parsers will throw errors before you even get to evaluation, if this was a simple grammar my position would be a bit more accommodating, but it isn’t, there are like two complete parsers that I know of (ypids is not one of them) and all the rest already have problems with the full grammar as is and adding an essentially random two token string is making things worse for everybody. Not to mention that you will start adding it automatically which will just lead to havoc.
Then I would clearly prefer Proposing `PH as usual` as extra value - #5 by mueschel (with public_holidays spelt out) that is at least benign and you get your confirmation that the user knows about public holidays.
I agree.
(for length: completely agree)
Indeed, not specifying PH in that case is even better than adding it to the set, because that addition completely changes what the set contains! The solution in this case is shorter still opening_hours = Mo-Fr 09:00-17:00 
Open Mo-Fr regardless whether PH or not.
That would be a shop that is open Mo-Fr and on PH, whatever day of the week. A rare case? @Pieter_Vander_Vennet - is this the case you want to solve? I think, no, that is not what you are after.
I think you are after an imaginary StreetComplete like quest: “No opening hours specified on PH, please verify!” The answer could be: “As usual”, then a opening_hours:public_holidays=same gets added and problem solved?
Hopefully something like this is adopted and then opening_hours evaluation tool will stop “warning” me “There was no PH (public holiday) specified” every time I want to validate some syntax 
(Where I map it is rare for shops to have consistent opening hours for all holidays, let alone post them)
3 Likes