[Tagging] opening_hours specification fix for values like Mar Su[-1]-Oct Su[-1]

Robin Schneider ypid at riseup.net
Sun Oct 22 12:13:31 UTC 2017


Support for opening_hours like `Mar Su[-1]-Oct Su[-1]` has been removed from the
[opening_hours specification] on accident by me back in 2013 which was noticed a
few weeks ago [1].

`Mar Su[-1]-Oct Su[-1]` describes a time range from the last Sunday of Mar until
(including) the last Sunday of Oct. This is needed to express the period of
summer time in Europe for example: `Mar Su[-1] - Oct Su[-1] - 1 days` ([2]).

This feature has been supported by Netzwolf‘s implementation [time_domain] at
last since 2013 and has been added to the current JS implementation [3] on
2013-10-13 [4].

The missing definition is:

<date_from> ≔ [ <year> ] <month> <wday> *[* <nth_entry> { , <nth_entry> } *]*

When you look into the [opening_hours specification], you will notice that this
addition will introduce ambiguity when parsing. For simple values like `Apr
Su[1]` the `Su[1]` could now either be considered as part of the <weekday_range>
or the <monthday_range>. This does not create an issue here because all
ambiguous cases end up being functional equivalent.

<date_from> ≔ [ <year> ] <month> <wday> *[* <nth_entry> { , <nth_entry> } *]*
<monthday_range> ≔ [ <year> ] <month
<monthday_range> ≔ <date_from>
<monthday_range> ≔ <date_from> [ <date_offset> ] - <date_to> [ <date_offset> ]

<weekday_range> ≔ <wday> *[* <nth_entry> { , <nth_entry> } *]*

(Only directly needed symbol counterparts are reproduced above.)

`Apr Su[1]` ≙ <monthday_range>
`Apr Su[1]` ≙ <monthday_range> <weekday_range>
`Apr Su[1]-Apr Su[1]` ≙ <monthday_range>
`Apr Su[1]` ≙ `Apr Su[1]-Apr Su[1]`

`Apr Su[1]` can be written as `Apr Su[1]-Apr Su[1]` which leaves no room
ambiguity anymore. This allows to compare the meaning programmatically because
[3] allows to compare two opening_hours values and interprets `Apr Su[1]` as
<monthday_range> <weekday_range>. The [evaluation tool] agrees that both
variants have the same meaning. Nevertheless, is is probably best to use the
opportunity to remove this ambiguity. This can be done by not allowing
<date_from> as defined above for:

<monthday_range> ≔ <date_from>

using a "Limitations and Explanation" comment.

There are currently 387 objects with opening_hours using <date_from> as defined
above which can be tested using [regex_search.js].

$ ./regex_search.js export.opening_hours.json
regex search> \w{3}\s*\w{2}\[\s*-?\s*\d+\s*\]
Matched 270 different values, total in use 387.
Print values? y
Matched (count: 44): Apr Fr[-1] - Sep 30
Matched (count: 11): Apr Fr[-1] - Sep 30 00:00-24:00
Matched (count: 10): Mar Su[-1]-Oct Su[-1] -1 day: 09:00-20:30; Oct Su[-1]-Mar
Su[-1] -1 day: 09:00-17:30
Matched (count: 7): Mo-Fr 10:00-20:30;Sa 09:30-18:00;Su 10:00-17:00;Jan 1
off;Feb Mo[2] off;Easter off;May Mo[-2] off;Jul 1 off;Sep Mo[1] off;Oct Mo[2]
off;Dec 25 off
Matched (count: 6): Jul Su[-1] -6 days-Jul Su[-1] 08:00-20:00

I would propose to re-add the missing <date_from> definition to the
specification without full proposal process on 2017-11-06 if no one disagrees.

Thanks to Simon Pool for prior discussion and for writing a second parser,
implementing the same spec which also helps with finding errors in the spec.

If we missed anything please do not hesitate to write.

[opening_hours specification]:
[1]: https://github.com/simonpoole/OpeningHoursFragment/issues/18
[2]: https://openingh.ypid.de/netzwolf_mirror/time_domain/explanation.html
[3]: https://github.com/opening-hours/opening_hours.js
[evaluation tool]: https://openingh.ypid.de/evaluation_tool/
[time_domain]: https://openingh.ypid.de/netzwolf_mirror/time_domain/form_hours.html

Live long and prosper
Robin `ypid` Schneider -- https://me.ypid.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20171022/eafc4922/attachment.sig>

More information about the Tagging mailing list