I was reading about how opening_hours rules work, and I’ve found this example:
May 01,03,09,21,27,31 08:00-21:00
It is a simplification of what I found here.
Why is this a valid rule?
According to the specification, it shouldn’t be possible to have multiple monthdays after a month, but the evaluation tool works with it, and that wiki editor also said it is valid.
I can confirm that I do not find any rule in the spec that would allow it. I guess the opening hours evaluation tool is just lenient here. Why, I can only speculate. Probably this syntax is unambiguous, so the author(s) of this tool decided that it is fine to support it. The spec-valid alternative after all would be
May 01,May 03,May 09,May 21,May 27,May 31 08:00-21:00
which is hideous.
@SimonPoole 's opening hours parser for Java (used by JOSM, Vespucci and StreetComplete) supports this too in “non-strict” mode. (Along with many other lenient parsing that is not ambiguous).
Thank you for the response! So sometimes the parsers can do a little more than what is in the spec, I see.
I have marked the solution, but I have one more question about this. What is your experience regarding “extensions” like this? If a popular parser supports an extension, is it usual that more (even if not all) other popular ones will support it?
I’m asking this to decide whether I can safely use “extended” syntax like above.
I don’t know. This is something where documentation in the wiki could be extended by for example a table of which parts of the opening hours syntax (within spec and additional to spec) are supported by each parser. (If you are interested in this and would like to research and document your findings in such a table, it would be greatly appreciated.)
What I know is that the openingh.openstreetmap.org tool is considered as somewhat of a reference implementation in the sense that many people use this tool to check if opening hours are valid.
Recently I’ve considered contributing to that wiki page, but I’m afraid it would require a little more work if I would be at it. The page tells about some possible syntaxes that are not actually in the spec, and also not supported by parsers, so I would first want to check what is correct and what isn’t.
The general problem is that the grammar is full of ambiguities, one offs and other oddities as is and non-strict parsing modes make things worse not better. Relaxing the rules on input makes sense in so far as it makes entering values without an UI somewhat simpler, but that is really the limits of the usefulness.
Do you mean with ambiguities that valid opening hours according to the spec could be interpreted to mean one thing or another thing? Or do you mean that the spec itself is ambiguous in what is valid and what is not valid? (Do you know an example?)
Just see the issues caused by the use of “,” as a rule seperator that are not expressed in the grammar.
And once we get in to non-strict territory things get wild.
Which exactly do you mean? Do you have an example?
You mean something like that?
Mo-Fr 08:00-12:00, Tu,Th 14:00-16:00