Mo,Sa,PH 12:00-18:00;Tu-Fr,PH 08:00-20:00
As said IMHO it isn’t necessary, and any validators that complain about missing PH are broken. But the grammar is concise and it would have to be an rare edge case for this to be more verbose than any working grammar extension (which the proposal isn’t).
No I’m not saying that, the opening hours grammar is.
The big issue with PH is which PH, Christmas Day and a Bank Holiday Monday are very different things.
Places like post offices and many small shops are easy as they close.
This does not work as expected (I tried in testing tool) - It shows Sunday, Nov 1 2026 as open same as on weekdays, which likely not the case.
The other case though handled fine. When Mo-Fr are PH.
First case needs one extra rule for Sa-Su then: Mo-Fr,PH 09:00-17:00; Sa-Su off to make it explicit, otherwise too expansive.
Ok, I think we finally get your point Simon (or at least I do). It is a shame that it took this long, plus some personal attacks. Setting out examples is a good way to get others to understand rather than blaming them for not reading the docs, especially when they are not straightforward/could be misinterpretted.
With that, I am happy with Simon’s approach to tagging. If we all agree, let’s add that as an example on the wiki.
You’d need to add “Su off”, then it works. So: opening_hours = Mo-Fr,PH 09:00-17:00; Sa-Su,PH off
I came up with that on my own, but I did not add PH a second time 
Guess not too much contrived that. But brings up something: We need to tag things that do not exist, in the words of another topic.
The testing tool parser has a number of issues particularly around holiday handling, that specific one is discussed “somewhere” and a good decade old, if I have too much time today I might go a dig out the reference.
I would never let an opportunity pass to give you a chance to pontificate.
Nope, the testing tool fails a different way then. This should show as open as it’s a Monday PH but it is showing as closed:
Edit: So they testing doesn’t work properly. No wonder folk have got confused here.
Yes, the grammar currently doesn’t cater for different kinds of holidays outside of the PH/SH difference (and it would likely be painful to graft it on).
From an evaluation implementation pov I would probably simply use the kind of object in question as an additional parameter to the PH data lookup given this is all external data anyway. So for example for bank holidays you would check if this is an establishment that typically respects them.
PS: we’ve had a essentially finished independent and complete evaluation library for many years that I should really unblock, the problem there is that the time zone handling, while not broken, relies on the OSM based GitHub - evansiroky/timezone-boundary-builder: A tool to extract data from Open Street Map (OSM) to build the boundaries of the world's timezones. · GitHub that works OK for server applications, but has impossible startup times for any end user app. But contrary to Ypids implementation it uses non-GPLed holiday data (nothing against share-alike for such applications, but the GPL variant is a pain).
No that’s not correct in general for the situation I was describing, since that value would set the hours on all PH days, not just Mo-Fr ones. (The Mo-Fr there could be replaced by any day range in general.) But you could use that idea, and write:
opening_hours = Mo-Fr,PH Mo-Fr 09:00-17:00
That’s less repetition than opening_hours = Mo-Fr 09:00-17:00; PH Mo-Fr 09:00-17:00 but you’re still having to repeat the day ranges each time. For more complicated situations, that could still be slightly cumbersome.
Edit: No, it turns out you can’t do what I was suggesting there with the current specification. <weekday_selector> does not allow you combine <holiday_sequence> <space> <weekday_sequence> with another <weekday_sequence>. So it looks like the only way to precisely be explicit about PH hours being the same as the corresponding day’s hours is to fully duplicate the rule for each <weekday_sequence>, i.e. opening_hours = Mo-Fr 09:00-17:00; PH Mo-Fr 09:00-17:00
I think the evaluation tool is correct here: Mo-Fr,PH 09:00-17:00; Sa-Su,PH off should evaluate to closed on any PH. Both rules apply to all PH days (the comma is essentially an “or” in the day ranges). Later rules override earlier ones, so the second rule’s “off” over-rides the times in the first rule if it’s a PH.
That is a parsing nightmare and very unlikely to happen. But this is a different case than what the extension was being proposed for, and IMHO a PH specific rule is what fits the bill here. Obviously we are now going to drift off into discussion of the 255 character limit on tags, but that’s an issue for all structured tags that we are going to have to address one day.
Since the proposed use case (PH varies with the weekday it falls on) is not covered by the current syntax, I think the proposal stands.
yes, it’s the simplistic German version of public holiday where all holidays are basically the same for most contexts, (although there are also some “commonly known” exceptions for e.g. xmas where some places that normally are open on PH, are closed as well, e.g. some museums, while others like restaurants, are more likely to be open). These very details for specific dates are hard to keep up to date IMHO, because it could change from one year to the other, similar to the individual holidays some (usually smaller) shops or offices may make (and which we do not map).
The proposed use case is that the opening hours are unchanged during public holidays. You might be talking about something else, but it is unclear what exactly.
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.