open_hours: closed the last day of each month ???

I can’t find how to denote that a spot is closed the last day of each month

Any idea?


opening_hours=closed “Closed on the last day in the month”

Above should work with open times placed before the closed limiter.
Please see paragraph “Closed on last weekend in month” on webpage :-

I don’t think that’s a solution. How is an application supposed to parse that to show spots open right now?

By the way, I tried
-1 off
and got an error on JOSM:
Unexpected token: “-” Invalid/unsupported syntax

The only thing that seems to work for is

open; PH open;Jan 31, Mar 31,May 31, Jul 31, Aug 31, Oct 31, Dec 31, Apr 30, Jun 30, Sep 30, Nov 30, Feb 28 off; Feb 29 off

which is not correct for February.

[Edit changed Feb dates]

I opted for
-1 off
inspite of the JOSM complaint, since it’s mentioned in the specification of opening_hours

The string

-1 off

is not valid for the syntax defined in, so JOSM complains and most probably other apps are unable to undestand what you are trying to write.

I refer to the main article for opening_hours

-1 off should be correct according to the quote from there:

Syntax for specifying dates (with optional times)
dates: monthly | weekly | daily | variably | holidays
monthly: monthdays [ weekdays ]
monthdays: dd [ -dd ]
dd: a 2-digit monthday number in range 01-31, e.g. Dec 25

That quote says that the only use of “-” is to delimit the end from the beginning of the range, and also that “1” should be represented as “01”, so it DOES NOT support the use of “-1”.


There is currently no easy syntax defined to express this. I noticed this already and included it in the TODO of the evaluation_tool/lib. Someone would need to some up with a good saytax and do a proposal so that we have a standard for this.

I would propose something like

opening_hours=monthday -1 off "Closed on the last day each month"
opening_hours=monthday 1 off "Closed on the first day each month"

The monthday is a keyword followed by a list of monthdays. Similar elements already exist in the syntax which also start with a keyword like week or comment.

What happens if there is no such monthday for a month? I would say then the rule does not match for this month. That is just an idea.


Is the sentence “Closed on the last day each month” necessary?

Good question and sorry for the ambiguity. No, they are normal comments in the opening_hours syntax which I just reused/misused here.

This would be enough:

opening_hours=monthday -1 off
opening_hours=monthday 1 off

Oh no, not again.

Anyway, we already have a syntax for month day numeric values: please don’t confuse things by introducing yet another way of specifying them.

Further, there are other ways of approaching this outside of introducing a completely new grammar element, just to handle one special case.

For example create a special wildcard month, then it the value could be written as
opening_hours=EveryMonth 01 -1 day off

If the grammar allowed a month range plus a month day spec, it wouldn’t even need that

opening_hours=Jan-Dec 01 -1 day off

that would need to be checked if it doesn’t conflict with anything else.

@ypid the evaluator currently barfs on “Mar 03-Dec 01 -1 day off” which is however completely valid

PS: just in case that it wasn’t obvious, the correct way to express the last day of month closed for all months without any grammar changes is

Jan 01 - 1 day off; Feb 01 -1 day off; Mar 01 -1 day off; Apr 01 -1 day off; May 01 -1 day off; Jun 01 -1 day off; Jul 01 -1 day off; Aug 01 -1 day off; Sep 01 -1 day off; Oct 01 -1 day off; Nov 01 -1 day off; Dec 01 -1 day off

Thanks very much! I prefer your

opening_hours=Jan-Dec 01 -1 day off

I must have overlooked that -1 day can already be used to express this. Very nice. I am not completely sure that this extension of the syntax would not break anything but it sounds promising.

Nice, I missed that :slight_smile: Multiple <monthday_range> (s) can even be combined using a comma. So

Jan 01 - 1 day,Feb 01 -1 day,Mar 01 -1 day,Apr 01 -1 day,May 01 -1 day,Jun 01 -1 day,Jul 01 -1 day,Aug 01 -1 day,Sep 01 -1 day,Oct 01 -1 day,Nov 01 -1 day,Dec 01 -1 day open

should also work. The evaluation tool does not yet implement it. Sorry for this to take so long.

I’d prefer that kind of syntax with the special wildcard month to ease the job of both machine parsers and a humans.

I hope you didn’t proposed that nightmare as a solution :smiley:

yep →

:roll_eyes: :stuck_out_tongue:

That is actually how we started off with the current specification which ended with something that overall is neither really simple nor easy to build an UI around, all which could have been avoided with a less “simple” approach.


PS: naturally we could have used an existing spec, for example the very popular iCal, see for the core specs, it is only 148 pages long, so I’m sure you find it easy to digest.

Well I wasn’t saying it was particularly elegant :-), ypids version is a bit better. But the major issue with the above is that it is 227 characters long, leaving only 28 characters for the rest of the spec (plus a bit of white space that could be squeezed out).

We just have to acknowledge that is not possible for a specification to cover every arbitrary use case. Not all cases described in human language could be written in the specification language.

Suppose someone create “The New OSM OpeningHours Testing Church”, which religious services will be only in prime days, counting days as starting in 1 the OSM birthday. Its reasonable for the specification to support this use case?

I think the better solution without modifying the specification is to write as escada suggested.

open; PH open;Jan 31, Mar 31,May 31, Jul 31, Aug 31, Oct 31, Dec 31, Apr 30, Jun 30, Sep 30, Nov 30, Feb 28 off; Feb 29 off

which only differs from the real word in one day every leap year (Feb 28 will be open, but described as closed)
To improve this, you could use the fact that semantically the order of the counts, so adding “;2020 Feb 28, 2024 Feb 28, 2028 Feb 28 open”…

Writing as

open; PH open; Jan 31,Mar 31,May 31,Jul 31,Aug 31,Oct 31,Dec 31,Apr 30,Jun 30,Sep 30,Nov 30,Feb 28 off; Feb 29 off;2020 Feb 28, 2024 Feb 28, 2028 Feb 28, 2032 Feb 28, 2036 Feb 28 open

which is usable right now for the software already in use, at least until 2040…