Talk:Key:opening hours

Card only fuel stations

In the UK fuel stations may be 'card only' overnight on the pumps and the main kiosk is unstaffed Elwell 08:05, 30 April 2008 (UTC)

as regards to opening time, as you can get what your are looking for (gas), i would consider this open. type of money cash/credit should be a different tag ? Sergionaranja 21:13, 30 April 2008 (UTC)

Can be tagged with payment:cash:conditional=*. See Key:payment and Conditional restrictions Mateusz Konieczny (talk) 20:32, 6 March 2020 (UTC)

Can we use this for roads?

Can we use this for roads? (e.g. in parks that are open only during the day). This would be useful for routing software. -- OliverLondon 13:20, 12 May 2008 (UTC)

i see another example (e.g. summer only roads in high mountains etc.)--Sergionaranja 10:14, 15 May 2008 (UTC)

This should be checked to see if it can be merged or just opening_hours should not be used for ways/areas Key:access which describes Access time restrictions: date_on; date_off; day_on; day_off; hour_on; hour_off --Sergionaranja 09:46, 20 May 2008 (UTC)

Comments opening_hours addon (months & ways)

• (e.g.: opening_hours = Mo-Su 8:00-18:00; Apr 10-15 off; Jun 8:00-14:00; Aug off; Dec 25 off)
• months: Jan Feb Mar Apr May Jul Jun Aug Sep Oct Nov Dec
• posibility to aply opening_hours to ways

please comment..

Some restaurants have other opening times on holidays. --BDROEGE 20:54, 6 May 2008 (UTC)

this may go better on another tag like opening_months... ??--Sergionaranja 06:18, 7 May 2008 (UTC)

I thought rather of holidays (Assumption of Mary, All Saints)--BDROEGE 21:29, 15 May 2008 (UTC)

I think it's better to deal with these cases by extending the possible times to include months and use the principle that more specific dates override more general ones. So for a shop open every day but closed in August, we'd say

opening_hours = Mo-Su 8:00-18:00; Aug Mo-Su 0:00-0:00

we could also allow dates, such as opening_hours = Mo-Su 8:00-18:00; Aug 16-21 0:00-0:00; Dec 25 0:00-0:00 -- OliverLondon 10:21, 9 May 2008 (UTC)

i still think the off concept is more clear, it can be used for months also

such as opening_hours = Mo-Su 8:00-18:00; Jul off; Aug 16-21 off; Dec 25 off --Sergionaranja 16:13, 9 May 2008 (UTC)

Voting (2008)

Voting is open now, i sugest we keep voting as it is (some people have voted allready)

so if it gets aproved and if some more people agree on including months to openning_hours, then call a second round of votes to aprove that addon. --Sergionaranja 16:12, 9 May 2008 (UTC)

Voting happened from 2008-may-9 to 2008-may-17 (now closed)

• I approve this proposal --Sergionaranja 08:06, 9 May 2008 (UTC)
• I approve this proposal --MikeCollinson 08:42, 9 May 2008 (UTC)
• I approve this proposal --Sascha silbe 09:52, 9 May 2008 (UTC)
• I approve this proposal. --Eimai 10:54, 9 May 2008 (UTC)
• I approve this proposal. --BDROEGE 17:03, 9 May 2008 (UTC)
• I approve this proposal. --Franc 22:47, 9 May 2008 (UTC)
• I approve this proposal. --Master 14:50, 10 May 2008 (UTC)
• I approve this proposal. --Jldominguez 21:30, 10 May 2008 (UTC)
• I approve this proposal. -- Historybuff 13:37, 11 May 2008 (UTC)
• I approve this proposal. -- OliverLondon 13:19, 12 May 2008 (UTC)
• I approve this proposal. -- Vrabcak 18:51, 12 May 2008 (UTC)

the key opening_hours is approved as described above

Voting addon "month"

Voting happened from 2008-may-17 to 2008-may-25 (now closed)

subject of voting: add months to the syntax in the form:

(e.g.: opening_hours = Mo-Su 8:00-18:00; Apr 10-15 off; Jun 8:00-14:00; Aug off; Dec 25 off)

months: Jan Feb Mar Apr May Jul Jun Aug Sep Oct Nov Dec

• I approve this proposal. --Sergionaranja 16:36, 17 May 2008 (UTC)
• I approve this proposal. --BDROEGE 18:04, 17 May 2008 (UTC)
• I approve this proposal. --studerap 09:54, 18 May 2008 (UTC)
• I approve this proposal. --OliverLondon 15:51, 19 May 2008 (UTC)
• I approve this proposal. --Rene A 17:23, 19 May 2008 (UTC)
• I approve this proposal. -- Vrabcak 05:23, 20 May 2008 (UTC)

the addon month for opening_hours is approved as described above

Voting addon "way"

Voting happened from 2008-may-17 to 2008-may-25 (now closed)

subject of voting: apply opening_hours to ways

(e.g. in parks that are open only during the day; or summer-only roads in high mountains...)

• I approve this proposal. --DrMark 07:40, 18 May 2008 (UTC)
• I approve this proposal. --studerap 09:54, 18 May 2008 (UTC)
• I approve this proposal. Should apply to any OSM-Object, even relations if necessary. -- Fröstel 21:56, 18 May 2008 (UTC)
• I approve this proposal. -- OliverLondon 15:52, 19 May 2008 (UTC)
• I approve this proposal. in combination with Month proposal, Should apply to all OSM objects (e.g. routes which depend on ferry service) -- Rene A 17:25, 19 May 2008 (UTC)
• I approve this proposal. -- Vrabcak 05:24, 20 May 2008 (UTC)

the addon way for opening_hours is approved as described above

time zone, holidays

Which time zone is to be used when interpreting the given times? (that is, do we have a way to unambiguously determine the time zone for any given node and way, and if yes, does that time zone always apply to the specified times?)

Time zone is based on the geographical location, you could use the state or country admin boundary to determine the time zone, but this is something you'd need to do in the code of the app working it out. -- Delta foxtrot2 01:00, 12 May 2010 (UTC)

The problem of holiday opening hours is similar to this one, as holidays differ by region. (opening times may be defined by a facility as "Sa 08:00-20:00, Su 08:00-18:00, Holidays 08:00-21:00" for national/regional holidays in general; setting explicit times for, say, dec-25 means hard-coding the set of current regional holidays, which might be subject to change.) --Osm6150856065 16:28, 8 November 2008 (UTC)

PH = Public Holidays -- Delta foxtrot2 01:00, 12 May 2010 (UTC)

dropping the weekday requirement

The syntax of opening hours is now in use for other tags (examples include Key:lit and Proposed features/Extended conditions for access tags), and it it's not a rare situation to have time intervals that don't depend on weekdays. Could we drop the requirement to include weekdays and allow values like "10:00-18:00"? --Tordanik 19:10, 2 September 2009 (UTC)

to me it is allready as you propose. example opening_hours=15:00-20:00 means open all days of the year at that time interval. opening_hours=Mo-Fr 15:00-20:00 means open those days of the week, all weeks of the year at that time interval. hollydays=all not open time. so opening_hours=Mo-Fr 15:00-20:00; 21Jun-21Aug off --Sergionaranja 12:40, 8 October 2009 (UTC)

Well, the section "Syntax" offers "wd hh:mm-hh:mm" and "mo md hh:mm-hh:mm", but not simply "hh:mm-hh:mm", so that variant seems not to be documented. Of course, every human encountering it would understand it, but a parser relying on that syntax section might not. --Tordanik 13:17, 8 October 2009 (UTC)

This is such an obvious extension that I just added it to the "Syntax" section. --Cartinus 10:21, 20 December 2009 (UTC)

need syntax for holidays and workingdays

I often find information about holidays which are different to the weekday opening_hours. I propose: Wd=workingday and Hd=Holiday for weekday-tags.--skyper 10:11, 7 October 2009 (UTC)

Another way is widely used: opening_hours=Mo-Fr 08:00-17:00; PH off. The problem with workday is, that this might differ for different countries and even in the same country does the definition of "workingday" differ (e.g. for different facilities, jobs). Also it should be distinguished between public holiday and school holiday. Holidays have to be defined in the program which evaluates the opening hours (and they can be defined … hint opening_hours.js). --Ypid (talk) 10:52, 24 September 2013 (UTC)

opening_hours=Mo-Fr 08:00-17:00; PH off not cover first/second/last/etc. workway/weekend. The issue that it can be official workdays (Mo-Fr) or organization (Mo-Sa). For example POI have special time for last workday of month: 31 Monday is public holiday, so if it work Mo-Fr (major case) then this day will be 28 Friday, but if Mo-Sa then 29 Sarturday. However public workdays and weekends can cover major cases. --Tbicr (talk) 10:22, 15 February 2015 (UTC)

Closing time on the next day

I haven't seen an example where a closing time is very early in the morning of the next day. Can I assume that something like "Mo 08:00-01:30" will be interpreted as a shop opening at 8 a.m. on Monday then closing at 1:30 a.m. the next day?

This isn't defined yet, so developers can currently interpret it how they want (if they don't forget to deal with these special cases alltogether, that is). Currently, the safe way is to split this into two intervals if you want it to be machine-readable.

It might make sense to define it your way - I'm not perfectly sure, though. Would you say that it's always the first of the two days which is the one that is mentioned explicitly, also for (extreme) cases like "Mo 23:30-10:00" where most of the interval is in the second day? --Tordanik 17:40, 5 December 2009 (UTC)

For my example, that's how I've seen stores state their opening hours in their signage. An example is as follows:

 Mon-Thu 6:00 am -  1:30am
 Fri-Sat 6:00 am -  2:00am
 Sun     8:00 am - 11:30pm

It would be nice if I can encode this as is (converting to 24-hour format) instead of "Mo 06:00-24:00; Tu-Fr 00:00-01:30,06:00-24:00; Sa 00:00-02:00,06:00-24:00; Su 00:00-02:00,08:00-23:30".

Consider this example opening_hours=22:00-02:00; Tu 12:00-14:00. Following the specification, the rule for Tuesday should completely overwrite that day. Netzwolfs code does interpret it like this opening_hours=Tu 00:00-02:00,12:00-14:00;We 22:00-00:00 for Tuesday and Wednesday, which is probably not what you want. opening_hours.js does follow the rules: opening_hours=Mo 00:00-02:00,22:00-00:00; Tu 12:00-14:00;We 00:00-02:00,22:00-00:00. But Netzwolf came up with a solution: opening_hours=22:00-02:00, Tu 12:00-14:00 which will be interpreted as expected (opening_hours=Tu 00:00-02:00,12:00-14:00,22:00-00:00;We 00:00-02:00,22:00-00:00) --Ypid (talk) 17:30, 1 September 2013 (UTC)

I guess one good question to ask is if you yourself own such store with opening hours as in your extreme example, how would you state your opening hours to your customers? --seav 12:27, 9 December 2009 (UTC)

I would suggest allowing closing hours >24 for this instance. For example, "Mo-Fr 08:00-27:00" means that from Monday to Friday the store is open from 8am to 3am the following morning. This is clear, unambiguous, easy to write and parse, and also incredibly useful for bars and other late-night establishments.

To use the above example, it would be "Mo-Th 06:00-25:30; Fr-Sa 06:00-26:00; Su 08:00-23:30". This captures exactly what the signage states with no ambiguity. (This sort of greater-than-24-hour signage is common in Japan, incidentally, so there's precedent for this format.) BigPeteB 05:57, 22 June 2010 (UTC)

One of the base "rules" of OSM is to make thing easy for the mapper even at the cost for developers. Last time I had to write code for time periods including midnight, I simply added 24h to the end time if it was lower than the start time. Not a very difficult rule. If somebody managed to input a time >24h, it would have worked too (no rule necessary). So I would say: Just write it as human readable as is common in the area where you live. This means that if times >24h are common in Japan and times <24h are common in the Netherlands, then the code should be able to parse both. --Cartinus 10:52, 24 June 2010 (UTC)

+1. This is what I have been doing instinctively for late-closing pubs in Bristol. Adding 24 would be an annoying thing to remember; adding 24 is very easy rule for a computer. Lorp 12:15, 20 April 2011 (BST)

Museum opens only on request

How about using opening_hours=on_request for a museum, which has only opened on request? --Michi 00:17, 5 January 2010 (UTC)

Will it always open on request (during the night, on sundays etc.)? I'd consider the time when an opening can be requested the "opening hours", and I'd try to invent a "request required" tag or something like that. (Btw, do you have to request this in advance or can it be done when you are at the museum?) --Tordanik 09:57, 6 January 2010 (UTC)

Well, that depends mainly on the guide. I have small museums in mind, which are managed by individuals, rather than by cities or companies. So the time when an opening can be requested depends on the guide. E.g., you can try to phone him or her, and if he or she answers the phone, you can make a request, but if the phonecall is unanswered, you cannot make the request, of course.

Same thing with the real opening time after the request. If the guide has time and inclination, maybe he or she will guide a tour right now. --Michi 02:13, 7 January 2010 (UTC)

I support the introduction of this additional value. I often have the same need with doctors who only receive by appointment. A phone=* could be added to the object when the request should or could be made by phone.--Kaitu 23:36, 7 February 2010 (UTC)

Maybe it would be more clear to use opening_hours=by_appointment? That's the standard phrasing for doctor's office, and I think it's equally clear when applied to museums. BigPeteB 05:26, 28 June 2010 (UTC)

A google search for by appointment had 2.4 million results, while the search for on request only had 76,000 results. After that, I also think opening_hours=by_appointment is the better approach. --Michi 22:10, 1 August 2010 (UTC)

I like opening_hours=by_appointment and I'm using it for Roseville Telephone Museum. T99 (talk) 18:52, 14 September 2013 (UTC)

Note that (currently) no parser out there will understand the keyword opening_hours=by_appointment. Consider using it in double quotes (e.g. opening_hours="by_appointment"). This has the big advantage that a parser for this value does not need to know all x special keywords, instead the value within the double quotes is just interpreted as comment and the state is unknown which can be reported to the user. --Ypid (talk) 20:42, 17 September 2013 (UTC)

Especially when tagging opening_hours of doctors, lawyers etc. there often is an additionally on_request to regular, periodic opening_hours. How to tag that? like opening_hours=Mo-Fr 09:00-12:30, 15:00-18:30; on_request ? --Jongleur 11:21, 28 July 2010 (UTC)

In my understanding, opening_hours=Mo-Sa 08:00-18:00; appointment means that it's open for anyone weekdays, and you need to have an appointment to visit in the evening or on Sunday. On the other hand, opening_hours=Mo-Sa 08:00-18:00 appointment (without the semicolon) means that you can only go there weekdays with an appointment, and you cannot get appointments for the evening or for Sundays. --Head 13:18, 26 April 2011 (BST)

Comments can be used to cover all of those cases. opening_hours=Mo-Sa 08:00-18:00 open "on appointment", opening_hours="on appointment", opening_hours=Mo-Sa 08:00-18:00 open "appointment not required" || "only on appointment" (Key:opening_hours:specification) --Ypid (talk) 19:15, 27 August 2013 (UTC)

Yes, of course comments can cover all of those cases. Still, the whole point of this spec is to be machine-readable, so including at least the most common cases in the spec seems necessary. On for key:opening_hours, you can see that currently all of "on␣appointment", "by appointment", by appointment, By Appointment, "appointment", By appointment, on appointment, "by appointment only" is being used. That means the fact that opening hours are "by appointment" only is impossible to extract automatically. Still, that would be useful for example to offer users a way to filter out theses amenities, when they are looking for something to visit at short notice.

(Rough) spec proposal:

In your grammar, allow a new modifier "by_appointment". Then the tagging opening_hours=by_appointment would become legal, and for more complex opening hours, things like "8:00-12:00 open; 14:00-18; by_appointment; PH off" would work, too. This should be simple and in line with the spirit of your spec. Would that work?

Alternative:

A new tag, "opening_hours:by_appointment", with the same syntax as "opening_hours" (for complex cases), plus a special value of "yes" meaning "by appointment, times not specified". Disadvantage: makes the spec more complex. Advantage: Backwards compatible for existing parsers.

Should I open a request somehwere?

Sleske (talk) 08:09, 11 August 2015 (UTC)

Please follow the normal proposal process. Examples: Proposed_features/opening_hours_open_end_fixed_time_extension, Proposed_features/opening_hours_holiday_select. Your example opening_hours=8:00-12:00 open; 14:00-18; by_appointment; PH off looks a bit wired. What should the third rule "by_appointment" mean. Normally without any selectors, the modifier by_appointment would match anything and would thus overwrite the previous two rules. Also "14:00-18" is invalid. I have said something about constant values on this talk page. You can have a look when you want to write an proposal.--Ypid (talk) 18:56, 11 August 2015 (UTC)

Thanks for the hints and advice. I'll think this through, and try to come up with a proper proposal. Actually, a separate tag (like "opening_hours:by_appointment") looks best to me right now - the spec for "opening_hours" is already quite complex (though admirably well designed), I don't think another extension is a good idea (plus, the "by appointment" hours could actually overlap with regular opening hours, which would clash with the existing spec). I'll see what I can come up with. Sleske (talk) 22:28, 13 August 2015 (UTC)

All right. But I don’t think that adding another tag (for example "opening_hours:by_appointment") would make this easier … You can propose to extend the syntax and keep it flexible that way (there is more than just "by appointment" which can be defined that way). Overlapping is not a real problem, at least with the current approach (using comments). Tagging "by appointment" has already been discussed (mailing list and wiki). The key thing is probably to define the constance.--Ypid (talk) 15:26, 14 August 2015 (UTC)

International standard for date and time

Have you considered using the international standard for representing dates and times? It covers up pretty much everything already proposed (excluding the sunrise/sunset keyword suggested above) like intervals and durations. Maybe it's not yet too late to change the current practise if we want to support the standardized way of writing dates and times.

We don't need dates or durations, though. We need repeated intervals without start and end dates. I don't know whether and how ISO 8601 supports this. What, for example, would be the ISO 8601 equivalent to our "Mo-Fr 08:00-19:00"? --Tordanik 16:25, 21 March 2010 (UTC)

The ISO 8601 does not seem very accurate. The RFC 5545, with RRULE, [1] would be more accurate, but not easy to write. --FrViPofm 21:49, 21 March 2010 (UTC)

On a second thought ISO 8601 does not seem sufficient as it would be cumbersome to specify weekdays with it. This week of the year would be 2010-W11 and you can also add a weekday to it as a number (from Monday=1 to Sunday=7), explicitly 2010-W11-7. The first two fields should be eliminated though in order to specify any Sunday which will leave us with a simple number, 7. Not very intuitive, the current practise using the English abbreviation, Su, is much better. I had also in mind the idea to eliminate the language dependance of the syntax but on the other hand all the keywords are in English anyway.

Maybe the RFC 5545 suggested by FrViPofm would suit us better but I haven't had yet time to give it a look. Does it have a way to specify "all working days" i.e. all days except Sundays (and Saturdays in some countries) and holidays? At the moment we can do it using an exception, for example "Mo-Fr x:xx-y:yy; PH off". -- Mikalaari 22:26, 21 March 2010 (UTC)

very complex opening hours

Opening hours:

Tuesday - Saturday 17:30 - midnight.

Sonn + holiday 11:30 - 2 pm and 6 pm - midnight.

Kitchen until 10 pm.

Monday - closed.

Bi-weekly Monday + Tuesday closed.

Table reservation only by call!

opening_hours = "Di-Sa 17:30-24:00; Su 11:30-14:00, 18:00-24:00; Mo off"

note = "Table reservation only by call!"

But how to tag the Biweekly thing and the kitchen thing and the holiday thing?

--Bürste 15:27, 19 April 2010 (UTC)

• The kitchen would need a separate tag (that would use the time interval / opening_hours syntax too, but a different key) describing when a facility serves food, so if you want to tag this, you should probably invent a nice key name.

• This tag does exist by now opening_hours:kitchen=* although it is not yet used widely. There is one open question about sub domain opening_hours like opening_hours:kitchen=*, should we copy the whole opening_hours=* again and change it (limit the opening_hours for the kitchen) or should we just write something like opening_hours=Mo-Fr 07:00-15:00,17:00-23:30; Sa sunrise-sunset; Dec 24 off and because the kitchen is only open when the facility is open just write opening_hours:kitchen=08:00-22:00. I propose the second approach. Are there cases in which this would not work? --Ypid (talk) 19:30, 27 August 2013 (UTC)

• Someone has already added PH as an abbreviation for "public holiday" to this page, so can already be described.
• As for the "biweekly" - that's not even properly defined in the original context, unless they specify when it starts, and whether the holiday rule has precedence over the biweekly rule, and how it continues after an holiday interrupts the rhythm. So you can't really decide whether its open unless you are a regular customer or call them and ask... --Tordanik 15:57, 20 April 2010 (UTC)

For the "biweekly" case we could add a new specifier for weeks, say a "W" followed by the week number, i.e. the first week (of the year) would be "W1". It could be used where the month specifier is used at the moment, but also after a month to indicate which week of the month the opening hours are valid for. The third week of April would be "Apr W3".

Of course a range of weeks could be expressed too, like "W44-50". Another convention has to be yet adopted to indicate every n'th week. A simple "Wa/n" should do, where a is the first week of the series. Now "W1/2" means the weeks 1,3,5,7,... and "W2/2" means the weeks 2,4,6,8,...

One could give a range for a, for example "W12-18/2" stands for the weeks 12,14,16,18 and "W27-45/3" for the weeks 27,30,33,...,42,45. --Mikalaari 07:26, 22 April 2010 (UTC)

You assume that a biweekly rhythm will start on week n each year. You also assume that there will never be any shifts due to holidays or similar interferences. These assumptions are likely incorrect for many cases, and allowing for them to be expressed would make this syntax even more complicated. And, most importantly, I have yet to see a shop that defines it opening hours with that amount of precision. --Tordanik 08:26, 22 April 2010 (UTC)

Yes, I forgot to add that in this particular case, for the very least, one should first find out what is the biweekly rhythm in question. Also one should never abuse tags and the suggested week expression is not an exception. However, if there are clear cases where it could be applied, I can't see why it (or something similar) shouldn't.

Closing x minutes after closing of other object

The multi storey parking closes 60 minutes after the end of the last movie in the cinema around the corner.

??

This kind of opening (or, rather, closing) hour would need a modification to the actual syntax. It could be something like "opening_hours:human_readable=<description of the opening hours for human beings>" since it would be very difficult to put in a machine readable text. A quite easy alternative is to give an approximate closing hour -- for example "8:00-~23:00" where ~ indicates that the time is not precise. --Mikalaari 09:09, 24 April 2010 (UTC)

or note:opening_hours that would be more OSM compliant. --FrViPofm 07:23, 27 April 2010 (UTC)

note:opening_hours:lg is even better, where lg stands fro the language, e.g. en for English, de for German Lulu-Ann

Key:note is for internal communication, i.e. explaining something to other mappers. For texts that are intended for end users, description:opening_hours (or, as with all localizable strings, description:opening_hours:lg) would be the better choice - see Key:description. --Tordanik 18:29, 28 April 2010 (UTC)

Day before public holidays

While mapping the city of Aachen, I've come across two places where I need to enter a time interval "one day before a public holiday".

• The road Metzgerstraße is closed to traffic Friday night, Saturday night, and the night before a public holiday.
• The disco Tanzpalast Elysée is open Fridays, Saturdays and before public holidays from 21:00 to 06:00 (see above for "closes next day in the morning" discussion).

I suggest mapping it like this: opening_hours=Fr, Sa, (PH-1) 21:00-06:00. What do you think? --Head 23:18, 21 August 2010 (BST)

I prefer something like BPH/BSH or bPH/bSH (before public/school holiday). That does not complicate the syntax with parentheses. -- Oli-Wan 12:06, 30 September 2010 (BST)

I prefer "(PH-1)" over "bPH" etc. It's much more flexible if you can parse specific days surrounded by brackets. What would you do if some shop closes 2 days before public holidays. Easy with "(PH-2), (PH-1), PH off". It's also more intuitive.--LetzFetz 12:18, 31 May 2011 (BST)

This can already be done, when the public holiday is on a fixed date. It can also be done, if the day is relative to easter or if the day is relative to a weekday in a fixed week of a fixed month. There are also some other possible cases, but tese are the most common public holodays. Netzwolf asked the German community for translation of http://www.netzwolf.info/kartografie/osm/time_domain/erklaerung, but it was not translated until now. This should be done, as this specification is based on the current used opening_hours schema and covers most special cases, which wehere found by discussion. --Fabi2 23:45, 31 May 2011 (BST)

1st sunday each month

What about when a store has open on the first (or 2nd or last etc) sunday each month, and closed the others? It is rather common here in Denmark.

Proposal:

Mo-Sa 10:00-18:00; 1st Su 12:00-15:00;

Mo-Sa 10:00-18:00; 2nd Su 12:00-15:00;

Mo-Sa 10:00-18:00; last Su 12:00-15:00;

Opinions?-- EsbenDamgaard 11:01, 6 октября 2010‎

Now there is [n] option

Mo-Sa 10:00-18:00; Su[1] 12:00-15:00;

Mo-Sa 10:00-18:00; Su[2] 12:00-15:00;

Mo-Sa 10:00-18:00; Su[3] 12:00-15:00;

For last Sunday of month

Mo-Sa 10:00-18:00; Su[-1] 12:00-15:00;

--Bigopenmac (talk) 19:06, 17 May 2015 (UTC)

Personally, I'm wondering if writing "1st" wouldn't be the better solution than [1]. The latter is pretty cryptic and not at all self-documenting. --Tordanik 11:44, 19 May 2015 (UTC)

Every 8 days

In the West region of Cameroon, village marketplaces are often every 8 days. I have been told that this is because the traditional Bamileke calendar uses an 8 day week. (See for example http://en.wikipedia.org/wiki/West_Region_%28Cameroon%29 .) How should I tag this? I was just going to put "every 8 days" for the moment..

Term-time?

The Bristol International Student Centre lists its opening hours as "1pm-5pm during term time". Any proposals for how to tag this? Listed as opening_hours=13:00-17:00 for now.

If in doubt just use comments. opening_hours=13:00-17:00 unknown "only during term-time" or try to specify term-time somehow using the approached syntax. --Ypid (talk) 19:37, 27 August 2013 (UTC)

odd/even dates

Tagging some roadside parking restrictions I remembered and came across a case not yet mentioned: odd/even date. It isn't used much, but some streets allow parking on one side only every other day; on one side 1st, 3rd, 5th of every month (and so on) and on the remaining days on the the other side. Mappers are naturally using the opening_hours scheme for the restriction validity intervals so I'm mentioning it here. In once case I tagged such as parking:condition:right:time_interval=odd 08:00-18:00 Alv 08:04, 10 January 2011 (UTC)

I think even and odd weeks also needed. In Hungary some GP is biweekly in the office on specified days and its important to note this in opening_hours. In tagging rules there is a row: "non-consecitive or semi-consecutive days of the week will be tagged as wd[x] (eg Su[3] 09:00-12:00)". I propose to extend this with even and odd like this: Fr[odd] 09:00-12:00. --BáthoryPéter 09:45, 4 November 2011 (UTC)

According to Netzwolf specification, "every n" is specified as "/n". Odd-Even is just a particular case, which is covered by this specification. Thus:
odd days: "1.-31./2"
even days: "2.-30./2"
odd weeks: "week 1-51/2"
even weeks: "week 2-52/2"
odd Fridays from 9 to 12: "week 1-51/2 Fr 09:00-12:00" --Kaitu 22:38, 4 November 2011 (UTC)

Thanks for the useful link and description! There would be the place in Rules section. --BáthoryPéter 21:55, 5 November 2011 (UTC)

does not seem to work in that format... I can specify it for one month like "Dec 1-31/2 08:00-17:00" but I cannot figure out how to specify it for whole year (except by repeating such rules for each month, which would likely hit 255 character limit)? It seems to be a bug: https://github.com/opening-hours/opening_hours.js/issues/252 --mnalis (talk) 00:13, 14 December 2021 (UTC)

@Mnalis: This is related to #First half of month, which typically would also apply to every month. – Minh Nguyễn ^💬 01:24, 14 December 2021 (UTC)

separate moving holidays/religious days

I have to map the opening times of a sauna. It opens 360 days a year. New Year's Eve and Christmas are easily mappable by writing: "Dec 24-25, Dec 31 off" But they also don't open at Whitsun and Easter. These specific days are different every year and Easter depends on the moon. Any suggestions how to do that? Otherwise such religious days would need their own keywords.--LetzFetz 19:31, 29 May 2011 (BST)

I think we should use something like "RH" (as for public holidays) with additional religion=*. Jewish has a lot of religious holidays and shops or synagogues may not work on it. And these days cannot be described by common rules VlIvYur (talk) 22:41, 18 November 2018 (UTC)

I don't know how I feel about the "RH" VlIvYur suggested, but "eid" is already in use. At least a small amount in the UK, with the same syntax as "easter", to me the syntax makes sense, but the value max length of 255 already gets tight. I don't really have a great solution in mind. --CjMalone (talk) 11:36, 20 January 2020 (UTC)

With the current opening_hours syntax, "easter" is supported, and whitsun can be written as "easter +49 days" --dfaure (talk) 22:00, 21 March 2021 (UTC)

women/men-only days

Some saunas have days when only women are allowed. Basically they are open at these days but men can't enter so you have to mark this. Maybe a comment value could be added. Like "//Thursdays women-only//". That could be parsed by websites/apps/whatever and could be displayed below the opening hours.--LetzFetz 19:31, 29th May 2011 (BST)

I would add one node for men's sauna and one for women's sauna and tag the opening hours on the correct node for a first try.

Lulu-Ann

Comments can be added … I would recommend the following. Use one node and write something like opening_hours=Mo-We 09:00-17:00 open "male only"; Th 09:00-19:00 open "male and female"; Fr-Sa 09:00-17:00 open "female only". I would propose to use some English default comments which can be translated by the software which is evaluating the thing. This would also have the advantage that this restriction could be evaluated by software. So it would be possible to return female=yes for example. --Ypid (talk) 19:49, 27 August 2013 (UTC)

You have to decide whether you want constants for evaluation in software or "comments". Comments would preferably be in the local language, unlike constant values for parsing. --Tordanik 20:00, 27 August 2013 (UTC)

Good point. Maybe we could use single quotes for constants? But this would also add more complexity for the mapper. Example opening_hours=Mo-We 09:00-17:00 open 'male only'; Th 09:00-19:00 open "everyone"; Fr-Sa 09:00-17:00 open 'female only' --Ypid (talk) 20:05, 27 August 2013 (UTC)

If we ever go that way, I would propose that we just use "special comments" for this instead. Like a valid JSON inside a comment which could be used to change other tags based on the time. For example: opening_hours=Mo-We 09:00-17:00 open "{'t':{'male':'yes'}}"; Fr-Sa 09:00-17:00 open "{'t':{'female':'yes'}}". The 't' stands for 'tag' to allow more flexibility. All tags in the 't' object could be added to the tags if the rule applies. Additionally, a 'c' could be used to still specify a regular comment. Although strings in JSON are defined to be surrounded by double quotes, I would recommend single quotes in this case … --Ypid (talk) 18:06, 21 August 2014 (UTC)

Daylight Savings

Presumably the times used by the opening_hours key are local time? Wouldn’t it be better to permit UTC time so that adjustment for daylight savings can be done externally? Perhaps that could be stated by adding " UTC" to the end of the value tag. For example, large numbers of street lights in England are being programmed to become unlit between midnight-05:00 GMT and 01:00-06:00 BST. These could be tagged with lit="sunset-00:00,05:00-sunrise UTC".

Specifying the timezone is currently not support. You might want to write an proposal for it. Anyway, you might be able to express this with the current syntax already. User:Netzwolf has given examples (and wrote the specification for it) to apply different opening hours for the Central European Time. opening_hours=Mar Su[-1]-Oct Su[-1] -1 day open "standard clock time is Central European Summer Time (CEST) (UTC+02:00)" and opening_hours=Oct Su[-1]-Mar Su[-1] -1 day open "standard clock time is Central European Time (CET) (UTC+01:00)".--Ypid (talk) 12:49, 18 October 2015 (UTC)

Bus during festival

Is this correct?

There is a bus service during a festival from 27. July 2011 until 14. August 2011. I felt free to add the opening_hours tag to a bus route relation.

opening_hours=Jul 27 - Aug 14

887209 887209

Can I add the year? The festival is not exactly on the same date next year.

Buslinie 267: Bequem zum Maschseefest mit üstra Sonderbussen

Ohne Parkplatzsuche können die üstra Fahrgäste auch in diesem Jahr wieder zum Maschseefest fahren.
üstra setzt von Mittwoch, 27. Juli 2011, bis Sonntag, 14. August 2011, Busse auf der 
Sonderlinie 267 ein, die den Maschsee mit dem Kröpcke verbindet. Montags bis donnerstags fahren 
die Busse ab etwa 17.30 Uhr bis circa 0.30 Uhr.
Freitags und sonntags verkehren sie zwischen etwa 16 Uhr und circa 3 Uhr. Sonntags fahren sie von 
etwa 13 Uhr bis 0.30 Uhr. Die Busse bedienen in beiden Fahrtrichtungen die Haltestellen 
„Maschsee/Strandbad“, „Maschsee/Löwenbastion“, „Maschsee/Altenbekener Damm“, 
„Maschsee Geibelstraße“, „Maschsee Funkhaus“, „Maschsee Sprengel Museum“,
„Rathaus Bleichenstraße“, „Aegidientorplatz“ und „Kröpcke“. 

Lulu-Ann

Daily opening hours

Whats about dailiy opening hours? Should I use opening_hours=Daily 9:00-21:00 or opening_hours=Mo-Su 9:00-21:00? --Saerdnaer 05:13, 29 August 2011 (BST)

"Mo-Su 9:00-21:00" is the common way, as taginfo shows. "Daily" isn't mentioned, and therefore will most likely remain unsupported if anything utilises these values. Alv 07:26, 29 August 2011 (BST)

I totally forgot to look at taginfo. It seems that opening_hours=9:00-21:00 is also an common way. Maybe someone should clarify the best/recommended way on the key page. --Saerdnaer 08:03, 29 August 2011 (BST)

Complex opening hours that depends on month/season

What about this one? (from http://www.gaaspercamping.nl/en/index.html )

March 	10.00AM - 12.00PM  1.30 PM - 6.00PM
April 	09.00AM - 12.00PM  1.30 PM - 7.00PM
-Th 21 April	09:00AM - 12:00PM   1:30PM - 9:00PM
-Fr 22 April	09:00AM - 12:00PM   1:30PM - 9:30PM
-Fr 29 April	09:00AM - 12:00PM   1:30PM - 9:30PM
May 	09.00AM - 12.00PM  1.30 PM - 7.00PM
June 	09.00AM - 12.00PM  1.30 PM - 8.00PM
-We 1 June	09:00AM - 12:00PM   1:30PM - 9:00PM
-Th 2 June	09:00AM - 12:00PM   1:30PM - 9:30PM
-Fr 10 June	09:00AM - 12:00PM   1:30PM - 9:30PM
July/Aug. 	
09.00AM -	9.30PM
September  	09.00AM - 12.00PM  1.30 PM - 8.00PM
October  	09.00AM - 12.00PM  1.30 PM - 7.00PM

Thats a hard one. Also because they seem to change every year … But the only real problem here that could come in the way is the restricted length of values of 255 characters in OSM. --Ypid (talk) 19:58, 27 August 2013 (UTC)

The first step would be to combine as many like hours as possible into one rule. opening_hours=Mar 10:00-12:00,13:30-18:00;Apr,May,Oct 09:00-12:00,13:30-19:00;Jun,Sep 09:00-12:00,13:30-20:00;Jul,Aug 09:00-21:30 which is only 116 characters leaving 139 characters for the remaining 6 days which should be definable in only two more similar rules. --Skquinn (talk) 17:48, 7 May 2019 (UTC)

Opening hours may depend on the category of visitors

Hi, some categories may be allowed only during different ranges of hours:

• swimming-pool, museums: hours for schools only, hours for public access;
• recycling area: days for residential people, days for professional only.

Any ideas on how to store this information with the present key? Some specifier like opening_hours:public for example? Teuxe 11:58, 1 May 2012 (BST)

This is covered in Netzwolf examples, section "Fallback groups". Something like for example: <Mo-Fr 08:00-12:00 || Mo-Fr 14:00-16:00 open "schools only"> --Kaitu 00:17, 2 May 2012 (BST)

24/7 = always

The value 24/7 means "always", which is unusual in some cultures. For better clarity I suggest to allow the word always alternatively. --Bob K. 14:03, 15 October 2012 (BST)

This change is unlikely to happen, redefining of existing tags is happening very rarely. Mateusz Konieczny (talk) 20:31, 6 March 2020 (UTC)

You can use just "open" instead, but it gives you a warning from the evaluation tool. Fabi2 (talk) 15:30, 22 December 2023 (UTC)

Say

• 24/7
• 00:00-24:00

if the two are exactly equivalent. Jidanni (talk) 00:48, 27 August 2020 (UTC)

Closed on last weekend in month

This can currently not be expressed right. I specified it as close as possible, which will work in most months. opening_hours=Th-Sa 17:00+; Su,PH 11:00+; Sa[-1],Su[-1] closed "Closed on the last weekend in the month (if Sunday is in the next month this opening hours exception will not be interpreted right!!)". Anyone else with this issue? --Ypid (talk) 18:06, 8 September 2013 (UTC)

Using the sintax explained on Netzwolf examples, section "Date as fixed distance to another date", this should work: opening_hours=Th-Sa 17:00+; Su,PH 11:00+; Sa[-1],Sa[-1] + 1 days closed.--Kaitu (talk) 10:40, 10 September 2013 (UTC)

Great stuff :) Thank you very much. --Ypid (talk) 10:19, 11 September 2013 (UTC)

I tested it and the implementation by Netzwolf opening_hours=Su[-1] - 1 days: 12:00-13:00 does not parse this currently. Should be added but only for constrained weekdays to avoid stuff like this opening_hours=Su - 1 days: 12:00-13:00. I will add it too (opening_hours.js) sometime. --Ypid (talk) 10:31, 11 September 2013 (UTC)

Missing definition and syntax diagram

Posted on the tagging@openstreetmap.org list:
I've had multiple difficulties described here coding a simple opening-hours "always except one period". OpeningHoursEdit bugs and not finding how to represent "always" after reading the whole lot several times. Normally, always is 24/7 but I suspect protest against 24/7 + "off" time. So, I bet that nothing preceding "period off" means always. And, as you probably noticed that I don't take OSM as a betting game, I'm asking confirmation.

As it takes much time "reading the whole lot several times", I added a conventional syntax diagram as a synoptic. Please check it and see what must remain of the rest and how. Feel free to add as many [n] references as needed behind any diagram line to text below it. But please do not crowd the diagram itself with that text again, thanks.
--Papou (talk) 20:27, 19 October 2013 (UTC)

24/7 should only be used if it really means always. I recommend expressing it like this opening_hours=Mo-Su 00:00-24:00; Mo 15:00-16:00 off. You can use this tool to write and check your opening_hours=*. It can also assist you in that case [2].

A syntax diagram does already exist … formal specification. --Ypid (talk) 16:22, 26 October 2013 (UTC)

Everything settled on the mailing list, thanks.

"open" does not exist on Key:opening_hours and the list replied to use "24/7", then to not use "24/7" but ""

The problem with the other syntax diagram is that only very lucky persons found it because there was no link to it. I have added one. --Papou (talk) 21:53, 26 October 2013 (UTC)

Being as explicit as possible is probably the best suggestion opening_hours=* so I would rather suggest to write opening_hours=Mo-Su 00:00-24:00; Mo 15:00-16:00 off. --Ypid (talk) 21:07, 27 January 2014 (UTC)

I prefer opening_hours=Tu-Su 00:00-24:00; Mo 00:00-15:00,16:00-24:00 which is a bit more explicit and easier to visualize. --Skquinn (talk) 17:50, 7 May 2019 (UTC)

Expressing end at <variable_time> but not after <time>

This playground uses the opening hours definition "from 07:00 till sunset but not later than 19:00". I shortly thought about the requirement to implement a new syntax element for this but then I came up with a solution. Here is what can be done in those cases: opening_hours=07:00-sunset; 19:00-24:00 closed "closes at sunset but not later than 19:00"

The syntax for opening_hours=* is very powerful by now … --Ypid (talk) 11:52, 27 October 2013 (UTC)

Voting addon 18:00-22:00+

from 2013-11-25 to 2013-12-03.

subject of voting: add short form for fixed opening range followed by open end to the syntax in the form:

(e.g.: opening_hours=18:00-22:00+)

Should we support this syntax for a fix opening range continued by open end? This is currently used 35 times (regex \d{1,2}:\d{2}\s*-\s*\d{1,2}:\d{2}\s*\+). Another way of writing this is to use opening_hours=18:00-22:00,22:00+.

By supporting this, the syntax opening_hours=-18:00-22:00 should also be supported to have some uniformity.--Ypid (talk) 11:29, 25 November 2013 (UTC)

• I approve this proposal. I think this is a good extension as the current solution of A-B,B+ looks more like a hack than a solution. Good idea to also include -A-B for consistency! --Nadjita (talk) 16:42, 25 November 2013 (UTC)
• I abstain from this proposal. Only a very limited subset of the community finds votes held on wiki talk pages. Proposals require a 2 weeks RFC period and obligatory mails to the tagging list for a reason. --Tordanik 17:22, 25 November 2013 (UTC)
• I abstain from this proposal. - see explanation by Tordanik Bulwersator (talk) 19:37, 25 November 2013 (UTC)
• I like this proposal. --MasiMaster (talk) 21:52, 25 November 2013 (UTC)
• I oppose this proposal. The proposed extension is fine, but this is not a proposal page and - as Tordanik wrote - only a few people will find this. Please write a proper proposal, link from the opening_hours page to it and announce it on the mailing list. Thanks. --Imagic (talk) 07:44, 26 November 2013 (UTC)
• I approve this proposal. Hholzgra (talk) 17:53, 27 November 2013 (UTC)
• I abstain from this proposal. for the reason Tordanik noted. Also, while I would support A-B+, I don't support -A-B. This will probably be useful about nowhere (when would you go to a facility with such opening hours? - with open end, you go there and stay, but if you don't know when it opens, what will you do). Also, it took me quite some time to understand what the syntax is supposed to represent - even though it was presented here as similar to A-B+ - so I think it's quite unintuitive, while A-B+ is probably clear, especially as B+ is already part of the opening_hour syntax --Errt (talk) 21:34, 27 November 2013 (UTC)

It is a quite common scheme in low traffic locations though.. Erik Johansson (talk) 08:07, 29 November 2013 (UTC)

• I oppose this proposal. This is not the right way for a proposal --Foxxi59 (talk) 12:29, 30 November 2013 (UTC)

I see. Obviously times have changed :) Sorry for the inconvenience. I thought it is not a big extension to open a own proposal as with the other votes on this page. I am writing on the proposal for this now Proposed_features/opening_hours_open_end_fixed_time_extension. Please don’t vote here anymore. A new vote will begin in a few weeks following the steps described on Creating_a_proposal. --Ypid (talk) 11:58, 3 December 2013 (UTC)

"Some people don't fully agree with the following simplified diagram" - what is the problem?

Currently it is nearly useless as there is no information what is a problem and who thinks so. To person who added this: please, create section about what is wrong with simplified diagram. Bulwersator (talk) 09:36, 1 December 2013 (UTC)

First of all, opening_hours=* are difficult enough and if your simplified diagram helps to write valid opening_hours I have no problem with that but I would add myself to the people how "don't fully agree" with it. There are some reasons: 1. User:Netzwolf has already created a diagram which can be used very intuitively and exactly once you understand it (which is now maintained in the wiki) but you started writing this when the original diagram was gone and I have not put the link to the new one in a present place early enough. So if we now have two it would make maintaining both of them harder and keeping them in sync. 2. There are some things which are not so clear like in your legend the point with "[...]" and "[something]". Here is one symbol used to describe two things (repeatability and if it is optional, which is not the same). I am just saying … Documenting something like opening_hours in it's current state takes some thoughtful hours.--Ypid (talk) 15:45, 25 February 2014 (UTC)

Could we maybe remove the "Simplified syntax diagram" from the wiki? I enhanced the specification quite a bit and I think there is no real use case for the "Simplified syntax diagram" anymore. Any thoughts? Anyone using it? Any advantages over the full specification?--Ypid (talk) 17:53, 10 August 2014 (UTC)

The "enhanced" specification has numerous issues (see the talk page for it). In general the specification is overly complicated (even without the errors in the current grammar) and actually writing a parser for it is a major undertaking. SimonPoole (talk) 10:44, 19 August 2014 (UTC)

See my comment about (re)implementing a parser for the syntax here. Numerous issues … You said it yourself, it is "overly complicated". But I think I can handle that (on the software development and specification side). I only recently had the time to update the Key:opening_hours:specification and I guess there are still problems. So please make me aware of them … This is also the reason, why I have not updated the german translation completely because it was obvious that there are still open issues with the original version. Besides, I am not going to start to list all the numerous issues in the simplified syntax diagram … Ypid (talk) 00:05, 21 August 2014 (UTC)

I am not using it Mateusz Konieczny (talk) 17:17, 21 August 2014 (UTC)

BH?

Does anyone know what BH should mean. Is it PH?--Ypid (talk) 18:26, 30 December 2013 (UTC)

I guess you are right. Probably it's Bank Holiday, used in Commonwealth countries for a day similar to a Public Holiday. --Seddinerphilipp (talk) 12:16, 31 January 2014 (UTC)

Telephone hours and Self-service hours?

Telephone hours and Self-service hours? Our employment_agency here in Sweden has such hours apart from the "normal" opening hours. logictheo (talk) 23:52, 27 January 2015 (UTC)

or would that be phone_hours=* with the same format as opening_hours=*? I'll try to consult with my local community since this may be specific to Sweden. logictheo (talk) 23:54, 27 January 2015 (UTC)

Currently, taginfo returns the following used keys: 3 times opening_hours:phone=*, 2 times phone:opening_hours=* and 2 times contact:phone:opening_hours=*. So you can choose :) --Ypid (talk) 22:23, 2 February 2015 (UTC)

Thank you! Now one of my problems are solved! :) logictheo (talk) 09:36, 6 February 2015 (UTC)

replacement for date_on etc.

After this series of edits, thie page recommends to replace the date_on, date_off, day_on, day_off tags with opening_hours. I agree that they should be replaced. However, I remember these being documented in the context of restrictions (access, maxspeed, ...) on highways, where Conditional restrictions is the correct replacement. --Tordanik 10:03, 28 May 2015 (UTC)

This is not a "recommendation", but effectively published since long on the list of depreated tags (except that the listed tags were going now where because of red links). The "suggested replacement" was already on the "Deprecated features" pages since long.

May be the replacement is not the best one now, but then the "Deprecated features" page should be updated because this is what is currently suggested. If so you can change the target of the redirect that was recently created to remove the red links on these old tags, to point to another page within its appropriate section (or if needed you can replace the redirects by a true page displaying the status; but many features are grouped in the same page, just with a small section listing them. The "Deprecated features" page is just an list, which is still largely incomplete (and may be we can think about replacing the list by a category listing separate pages for individual tags with their own status and showing their current replacement).

If you have looked at the top of the "Deprecated features" pages, there's a strong warning about its meaning! It does NOT indicate any recommendation, and in fact just *suggests* possible replacements and instructs users to avoid automated or semi-automated massive replacements.

But effectively we lack information in the wiki about deprecated tags and those that are preferred (not all the prefered ones were really approved, they came into being prefered only de facto without any real opposition since they were introduced). And how to preserve the semantics or simplify the global interpretation of tags by organizing them. MAny things are still not documetned in the wiki because they were only discussed in valirous mailing lists or sometimes only in old IRC discussions (for which there remains absolutely no visible trace and to which many users never participate in their time, and don't know that they occured: IRC is a really bad tool for discussing long term solutions and for seeking a common agreement that can be recovered later). — Verdy_p ^(talk) 16:22, 28 May 2015 (UTC)

Per your remark, I also added the "Conditional_restriction" link (which was also present on the "Deprecated features" page: whose link was already present in the new section, but that I just made bold because you apparently did not see it!). I don't have any opinion about which solution is best, but "opening_hours" has a lot of use (alone, without using the conditional-restrictions created as extensions to existing key names, but hardly usable without listing the keys to which these extensions could be added). — Verdy_p ^(talk) 16:35, 28 May 2015 (UTC)

Simplified syntax

The simplified syntax section does not seem all too simple to me. It doesn't look inviting to read at all. A page that I created for new users that want to just casually add a simple o_h tag: User:M!dgard/How_to_map_opening_hours —M!dgard [ talk | projects | current proposal ] 10:05, 23 July 2015 (UTC)

This is related to "Some people don't fully agree with the following simplified diagram" - what is the problem?. I saw your how to map opening_hours before and I must say, I really like it. Please add a link to it on key page. Additionally, I think it is a good idea to move it to 'Key:opening_hours/tutorial'.--Ypid (talk) 10:28, 23 July 2015 (UTC)

I moved the tutorial and added a link on the page. Could native English speakers please check it and correct any quirks? —M!dgard [ talk | projects | current proposal ] 12:31, 23 July 2015 (UTC)

I am not an native English speaker, but on the opening_hours syntax side it looks good to me.--Ypid (talk) 20:06, 28 July 2015 (UTC)

discontinuted activity

the bakery next to my home is closed until a new baker reopen it.
Should I use the tag opening_hours=closed? delete the POI? modify the access=* to a dedicated value (to create maybe)?
--Hellopierre (talk) 16:31, 6 February 2016 (UTC)

I suggest using disused:shop=bakery (i.e. a Lifecycle prefix) to express the situation. --Tordanik 12:34, 8 February 2016 (UTC)

Very specific seasonal opening hours - character length problem!

Our local parks have very specific closing times depending on the time of year (same opening hour each day however).

I have created the string with YoHours

Jan 04-31 07:30-16:30; Feb 01-07,Oct 31-Nov 13 07:30-17:00; Feb 08-21,Oct 24-30 07:30-17:30; Feb 22-Mar 06 07:30-18:00; Mar 07-20,Oct 17-23 07:30-18:30; Mar 21-27,Oct 03-16 07:30-19:00; Apr 04-17,Aug 29-Sep 04 07:30-20:30; Mar 28-Apr 03,Sep 05-18 07:30-20:00; May 09-Jul 31 07:30-22:00; Aug 01-14,May 02-08 07:30-21:30; Aug 15-28,Apr 18-May 01 07:30-21:00; Sep 19-Oct 02 07:30-19:30

Obviously, the 300-character length of this is a problem. (it's unfortunate that YoHours doesn't recognise this as I had invested a lot of time in creating it) Any suggestions on how to get around this?

Try removing the leading zeros before the days in the month and the spaces after ";". --Fabi2 (talk) 01:02, 25 December 2023 (UTC)

A misleading example?

I find this example a bit misleading:

May-Sep: Mo-Fr 09:00-18:00; Sa,Su,PH 09:00-16:00; Oct-Apr: Mo-Fr 09:00-17:00; Sa 09:00-15:00

An example how month range can apply to multiple weekday rules.

IMHO it evokes that the opening hours on Saturday from May to September are 09:00-16:00, which is not the case. Since the result of the evaluation results from the last rule, which is applicable to the particular day, the opening times are 09:00-15:00.

Religion specific holidays

Frequently christian churches have common services_times for Sundays as well as denomination specific holidays. Those holidays are different than the PH (they can be the same, but not always). How should I mark such holidays? Right now I see only SH (school holidays) and PH (public holidays), is there any marker in use for church specific holidays (CH?) ?

Example: church service times are at 8:00 Mon-Sat, and at 9:00 and 12:00 on Sundays and church holidays.

Religion specific holidays: my thoughts

The subject of religious holidays has already been addressed twice on this page, without much discussion. A small search on TagInfo shows that the service_times key is mostly used for religious service times. But the opening hours often depend on it too. So it seems useful to address the problem.

At the moment we have three ways to indicate the specifics of religious times:

1. For the particular case of schools run by religious people, some services change their schedule depending on whether we are in school or not. For this we can use SH. However, if these schools are private and have their own vacations, we cannot distinguish between Public SH and Private SH.
2. For holidays that depend on Easter in the Gregorian Christian calendar, we have the keyword easter (unique keyword in "yearly_fest" in the syntax summary on the wiki).
3. For other religious holidays (which can be roughly inferred from the religion and denomination fields, plus, utopically, country and region), the best (and bad) solution for now is to use PH.

It is also possible to use comments, as a last resort, but ideally it should only be used to indicate highly variable times and the type of service (ultimately we could introduce suffixes to distinguish the type of service/activity, TagInfo seems to say that this has been done in very few places).

For each of the three points above, I propose an extension:

1. The introduction of the PrSH keyword for school vacations not necessarily aligned with public school vacations. Such a keyword could be used exactly as SH by consumers, with the addition of a warning.
2. The introduction of other keywords for annual religious holidays. This number of keywords should be kept minimal, but sufficient to describe all dates that depend solely or also on the lunar calendar (as is Easter) or other calendars.
3. The introduction of the keyword CH (church) or RH (religious) (both have been proposed, I prefer the second one) as a way to say the feast days in that place. Consumers could post a message (which would usually be sufficient), or coupled with calendar providers, could fully exploit it.

What do you think about it?

A discussion area for adding holidays should be added to point 2. In the wiki I would also be for adding a table of holidays and the way to encode them (for example: ash Wednesday: easter -46 days). —Preceding unsigned comment added by Mux4 (talk • contribs) 2023-03-02

comma-semicolon, overrides-not...

looking at one of the examples :

 Su-Tu 11:00-01:00, We-Th 11:00-03:00, Fr 11:00-06:00, Sa 11:00-07:00
 Because of the definition that following rules will overwrite previous once, times which span over midnight have to use additional rules which are separated by comma instead of semicolon.

i've always found it to be extremely confusing.

• why is there a rule of "overwriting" ? what's the benefit of it in this case ?
• what's the point in differencing between commas and semicolons in this case ? why couldn't user just write this ?
• that is the only place in the page where word "overwrite" is used, thus searching for the actual definition (and the reasoning behind it) is impossible. while some other places use "override", not that many users will stumble upon that.

 Su-Tu 11:00-01:00; We-Th 11:00-03:00; Fr 11:00-06:00; Sa 11:00-07:00

how could this be misinterpreted ?

please note that i'm aiming for user-friendliness. opening hours are complicated to enter in some cases already, and the above confuses me enough to just skip mapping them. i would expect novice users to do the same in such cases. admittedly, in quite many cases i've went "screw that" and just mapped them with semicolons.

--Richlv (talk) 21:03, 27 September 2016 (UTC)

Refer to https://github.com/westnordost/StreetComplete/issues/305 where this has been discussed recently.--Ypid (talk) 09:07, 29 June 2017 (UTC)

the short version is that later rules need to "overwrite" previous rules when they specify different behaviour for the "same" period. The only case in which you need to use additive (,) rules is when you have a time range extending past midnight and you have specified time ranges for that day. In all other cases "additive" rules are not really useful outside of allowing some cases to be expressed slightly more concise. With other words. If evaluation was specified so that extended time ranges were not considered as not using the next day, additive rules would be completely unnecessary.SimonPoole (talk) 11:10, 29 June 2017 (UTC)

Solving the issue differently would be very welcome. To me, encoding additivity as a comma seems rather obscure and not self-explanatory at all. We recommend against using abbreviations in tagging for a good reason, and this feels an order of magnitude worse. --Tordanik 16:45, 29 June 2017 (UTC)

I don’t particularly like encoding additivity as a comma either. The thing is, it is well established by now. One would need to do a proposal and have the time to actually do the migration somehow.--Ypid (talk) 17:44, 29 June 2017 (UTC)

Can someone just tell me how to do monthdays?

This parking in Pune, India is open on the 1st, 3rd, 9th, 21st and 31st of each month. How do I do this? I tried "01,03,09,21,31" and "Jan-Dec 01,03,09,21,31" and both gave errors in JOSM:

--ADepic (talk) 14:29, 3 August 2018 (UTC)

The issue is that there is no special syntax (shorter) for this. I only see one solution which is currently supported by the specification:

opening_hours=Jan 1,3,9,21,31,Feb 1,3,9,21,31,Mar 1,3,9,21,31,Apr 1,3,9,21,May 1,3,9,21,31,Jun 1,3,9,21,Jul 1,3,9,21,31,Aug 1,3,9,21,31,Sep 1,3,9,21,Oct 1,3,9,21,31,Nov 1,3,9,21,Dec 1,3,9,21,31 08:00-21:00; PH off --Ypid (talk) 19:20, 3 August 2018 (UTC)

CopperOppositeKindred (talk) 22:38, 26 May 2022 (UTC)

It looks to me the article is wrong on daily dates. Looking at the specification I think it's not possible to specify

- monthdays as a range

- multiple monthdays

- monthdays if months is more than one month

Possibly I misunderstand something, though, because I don't know why is ADepic's example valid, but according to https://openingh.openstreetmap.de/evaluation_tool it is.

is 24:00 an allowed time?

In the opening hours syntax summary (" HH: An absolute 2-digit hours number (in day, in 24h format, no am/pm) in range 00-23, e.g. Fr 08:30-20:00.") at Key:opening hours 24:00 is not allowed. However, further down on this page there are examples and rules which mention "24". Furthermore the 24 is mentioned on Key:opening_hours/specification#hour. This should be unified/clarified.

This question is a spin-off from the discussion at https://www.openstreetmap.org/changeset/65323655 . --aseerel4c26 (talk) 19:21, 13 December 2018 (UTC)

Proposed extension to supported syntax in the page.

Main article: Proposed features/opening hours extension 2019-03-14

Part A

times: Extend the maximum range for hours to 30 so that valid time could be up to 30:59. Useful when shops and such are printing time over 24 hours on their official notice, and might also carry different meanings when DST switch are involved. It also mean that Sa 24:00 will be an acceptable alternative representation Su 00:00, or Fr 27:00 can be interpreted as Sa 03:00 in most usual cases.

Simultaneously, specify that even if a time range is marked in the current way like Sa 22:00-06:00, The day variable given before only applies to the opening time, and that it would automatically lapse into Sunday for the part after the day change even if only "Sa" was specified. In other words, Sa 22:00-06:00 would mean (Sa 22:00)-(Su 06:00). This is actually the way people are now inputting such time, but it seems like it would be better if it can be spelled out on the wiki page. C933103 (talk) 01:10, 14 March 2019 (UTC)

Part B

holidays: Add BH to represent Bank Holiday.

offset_time: sign wd weeks, for example +3weeks to represent 3 weeks after a specific day. C933103 (talk) 01:10, 14 March 2019 (UTC)

What is wrong with existing way to tag it? Mateusz Konieczny (talk) 20:44, 14 March 2019 (UTC)

What is the existing way of representing "This feature will be open from 3 week before certain_event_day to 3 weeks after certain_event_day? I don't think it exists? C933103 (talk) 06:33, 19 March 2019 (UTC)

I, too, would like to know how I can tag an offset. I'm trying to add the hours for a restaurant that's open on PH, but closed the day after. How do I specify this? --SaftoRangen (talk) 01:05, 30 January 2020 (UTC)

Part C

Mth: Add L01/L02/L03/L04/L05/L06/L07/L08/L09/L10/L11/L12/L01leap/L02leap/L03leap/L04leap/L05leap/L06leap/L07leap/L08leap/L09leap/L10leap/L11leap/L12leap to represent Lunar month in East Asia Lunar (Lunisolar) Calendar using local time zone (Each lunar month start on the day when the new moon occur, and the time new moon occur will be different at different place because of time zone, so same lunar date might correspond to different days in different part of the earth simultaneously.

Solar Term: term1/term2. Use together with western Mth. For example Dec term2 represent winter solstice. Dec term2 +105 represent Hansik festival. Again depend on timezone.

tz identifier: {@tz identifier}/{@UTC sign hh:mm}, for example {@Asia/Shanghai}, used to represent the basis for time calculation that is different from the local timezone, for example L01 01 {@Asia/Shanghai} for Chinese New Year outside Chinese timezone, or L01 01 {@UTC+07:46} for those who are still using old Beijing local mean solar time to calculate the date. Use combined syntax like L01 01 -1 {@Asia/Shanghai} 16:00-21:00 off {@America/New_York} to express a shop located at somewhere using New York timezone would close at 4-9pm on the day before Chinese New Year. Seems like it won't work and need to be defined via other ways.

This proposed expansion still couldn't cover some Asian way of date keeping, for example Doyo ushi no hi day that's defined as "ushi" days (2nd day in 12-days week) after the "doyo" solar term (cannot be defined from the above solar term tagging scheme because it is a "miscellaneous" solar term defined as when the sun's ecliptic longitude reached 117 degree) but before risshu (Aug term1), or the Chinese/Korean version of dog days, which are defined as starting from the 7th day on the third 10-days week after Jun term2, and end on the 7th day on the second 10-day week after Aug term1. It might be better to expand the yearly_fest section of the scheme for these festivals instead when the need to represent features that dependent on these festivals arise.

Example: Operational days of a bus route that operate during the Qing Ming festival and the Double Nine festival, and weekends that envelop the two festivals, can be expressed as following: Apr term1;(Apr term1 -4weeks Su, PH)-(Apr term1 +3weeks Su, PH);(Apr term1 -2weeks Sa)-(Apr term1 +1weeks Sa);L09 09;(L09 09 -2weeks Su, PH)-(L09 09 +2weeks Su, PH);(L09 09 term1 -2weeks Sa)-(L09 09 term1 +1weeks Sa)

C933103 (talk) 17:53, 13 March 2019 (UTC)

Can I suggest splitting it multiple separate extensions rather one giant one? Mateusz Konieczny (talk) 21:51, 13 March 2019 (UTC)

editedC933103 (talk) 01:10, 14 March 2019 (UTC)

Need example for multiple time selectors within same month/week selector

Please help to make this into a valid expression and post it as one of examples. Style #1 seems more logical and concise, however the main validation tool: opening_hours evaluation tool only understands #2; I am not sure if that's bad expression or limitation of the tool.

1. Sep-May Mo-Fr 09:00-12:00,13:00-17:00, Sa-Su 09:00-18:00; Jun-Aug Mo-Fr 09:00-21:00, Sa-Su 09:00-18:00
2. Sep-May Mo-Fr 09:00-12:00,13:00-17:00; Sep-May Sa-Su 09:00-18:00; Jun-Aug Mo-Fr 09:00-12:00,13:00-17:00; Jun-Aug Sa-Su 08:00-20:00

--HubMiner (talk) 17:12, 20 May 2019 (UTC)

Is style 1 following Key:opening hours/specification? Mateusz Konieczny (talk) 16:56, 21 May 2019 (UTC)

"however the main validation tool: opening_hours evaluation tool only understands #2" - I just tested it at https://openingh.openstreetmap.de/evaluation_tool/ and it seems to be accepted, what is going wrong? 17:00, 21 May 2019 (UTC)

• Comma (additional rule separator) is listed within "time selector". If someone could confirm that, then let's add examples.
• As I asked, evaluation tool understands #2 and does not understand #1. Is #1 valid style?

--HubMiner (talk) 17:31, 22 May 2019 (UTC)

" and does not understand #1" I tried both and seem to be interpreted in exactly the same way. What is the difference in their interpretation or warning/error messages? Mateusz Konieczny (talk) 06:43, 23 May 2019 (UTC)

Thanks for bearing with this. Original example had a typo, please use these instead; use "-1 day" / "+1 day" to scroll to end of May.

1. Sep-May Mo-Fr 01:00-09:00,10:00-12:00, Sa-Su 06:00-12:00; Jun-Aug Mo-Fr 12:00-21:00, Sa-Su 12:00-24:00
2. Sep-May Mo-Fr 01:00-09:00,10:00-12:00; Sep-May Sa-Su 06:00-12:00; Jun-Aug Mo-Fr 12:00-21:00; Jun-Aug Sa-Su 12:00-24:00

Graph in #2 shows Sa-Su time as desired. #1 has the problem where Sa-Su is shown as 06:00-24:00, both in Sep-May and Jun-Aug ranges.

--HubMiner (talk) 17:17, 23 May 2019 (UTC)

"Staff only" times, or churches

Some technical offices have separate times for staff only. Jidanni (talk) 05:50, 24 August 2019 (UTC)

Many churches have times for meetings, but Mon-Fri business hours for the office. Or maybe always open for personal meditation but meetings at specific times. (Basically, humans are too unpredictable for any discrete set of options to be complete!) 伟思礼 (talk) 18:40, 6 March 2020 (UTC)

Are both religious ceremonies and office-related things done in exactly the same place? In Poland it is typical to map amenity=place_of_worship and office=religion separately, what allows to easily assign opening hours, service times, names etc Mateusz Konieczny (talk) 20:29, 6 March 2020 (UTC)

For the latter, you may consider service_times=*. "meetings" and events doesn't have anything to do with opening_hours=* of a amenity=place_of_worship directly. -- Kovposch (talk) 16:46, 8 March 2020 (UTC)

yearly, monthly

Some fairgrounds are only open from the last week in November to the third week in December... add yearly_fest examples. Jidanni (talk) 03:16, 21 November 2019 (UTC)

FROM an unknown or unspecified closing time example

We read

Su 10:00+
Sunday from 10:00 to an unknown or unspecified closing time.

Fine. But please add an example of how also how to write

Sunday from an unknown or unspecified opening time to 23:00.

We can only guess it is

Su +23:00

But maybe it is

Su -23:00

Nobody knows. Jidanni (talk) 01:05, 23 January 2020 (UTC)

Should be undefined/unspecified for all time elements. Read Key:opening hours/specification. Once proposed Proposed features/opening hours open until (can read http://gis.19327.n8.nabble.com/Feature-Proposal-RFC-opening-hours-open-until-td5797320.html). Kovposch (talk) 22:33, 2 February 2020 (UTC)

Then Su 10:00+ is wrong too? Jidanni (talk) 03:04, 6 February 2020 (UTC)

No, this is accepted. Kovposch (talk) 15:34, 6 February 2020 (UTC)

First half of month

I found this nice POI with different opening hours every month from 1st to 16th. [3]. The Mo-Fr opening can be handled by

Mo-Fr 08:30-17:00;  Jan 1-16,Feb 1-16,Mar 1-16,Apr 1-16,May 1-16,Jun 1-16,Jul 1-16,Aug 1-16,Sep 1-16,Oct 1-16,Nov 1-16,Dec 1-16 Mo-Fr 08:30-19:00

But is there any way to add Sa/Su times as well without stating all the months again? --Mueschel (talk) 13:26, 30 January 2021 (UTC)

No, you need to repeat everything again, unfortunately. It's the same as the example from the wiki page that says "Apr-Sep: Mo-Fr 09:00-13:00,14:00-18:00; Apr-Sep: Sa 10:00-13:00". I certainly wish there was a way to reuse a wide range selector for multiple weekdays with different hours. I'm reviewing many entries and most people assume that the wide range selector applies to everything until the next semicolon. That's not the case, but a new syntax for such purpose would be very useful. --dfaure (talk) 22:11, 20 February 2021 (UTC)

This would also be extremely useful for alternate parking. In some European countries it's quite common that you park on the left in the first half of any month, and on the right in the second half of the month. Joost schouppe (talk) 10:23, 3 November 2021 (UTC)

For reference and explanation of what this is and how it looks like https://en.wikipedia.org/wiki/Alternate-side_parking#Belgium

The only thing that would need to be adapted from the specification is https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification#date_from :

<date_from> does currently not allow month ranges while there is no good reason to not support this.

If it was specified to allow month ranges, it could simply be Jan-Dec 17-31: Mo-Fr 08:30-17:00, Jan-Dec 1-16: Mo-Fr 08:30-19:00 --Westnordost (talk) 15:00, 26 November 2021 (UTC)

All-month rules could be made shorter by reformatting as additional rules if using month days alone is allowed, without the need for months: opening_hours=08:30-17:00, 1-16 17:00-19:00 (if this looks sensible). ---- Kovposch (talk) 08:17, 27 November 2021 (UTC)

@Westnordost and Kovposch: I think month ranges is very sensible, even if it means some fudging about days at the end of the month. (I think Jan-Jun 20-31 should be OK; after all, data consumers already have to deal with the fact that Feb 29 is invalid most years.) Omitting the months altogether seems riskier: even if there's technically no ambiguity, it's so easy for a malformed user-inputted value to become ambiguous. If a user enters 7-9, do they mean the 7th through the 9th of every month or 7:00 AM to 9:00 AM? – Minh Nguyễn ^💬 03:22, 1 December 2021 (UTC)

Explicitly stating of PH required?

Does PH always has to be explicitly stated? In the western world, where public holidays usually count as Sundays, opening hours on a public holiday are usually the same as on Sundays, and businesses therefore usually don't specify them. Do I always have to add Su, PH closed or Su, PH ...-...? I've rarely come across a opening_hours tag with PH. --Dafadllyn (talk) 19:11, 1 April 2021 (UTC)

Given that the online evaluation tool [4] warns when PH isn't specified, I actually see PH in many many opening_hours values. If it's closed or equivalent to a Sunday, that's rather easy to add (the way you mention). Without any mention of PH, I guess most implementations will treat it "same as a normal day, i.e. use monday hours if it falls on a monday, use tuesday hours if it falls on a tuesday etc.". This use case actually makes sense, I saw it expressed explicitly recently. I agree it's not the most common, but I think that means we can't change the meaning at this point. --dfaure (talk) 21:00, 1 April 2021 (UTC)

In most times, a rule such as "; PH off" is needed, as everything is open, if the opening days are public holidays per default. This is a problem as many mappers, at least in Europe, especially StreetComplete users, don't think, that this is needed, and so many facilities are false-open on holidays. --Fabi2 (talk) 01:15, 25 December 2023 (UTC)

Permanently closed

https://help.openstreetmap.org/questions/697/how-to-mark-a-pub-as-permanently-closed

opening_hours=closed
disused=yes

perhaps. Jidanni (talk) 11:15, 12 July 2021 (UTC)

I would tag it disused:amenity=pub (see also Lifecycle prefix), because if it's permanently closed it's not a pub anymore. Besides, apps that don't evaluate all these tags would still display a pub if it's tagged amenity=pub + disused=yes or amenity=pub + opening_hours=closed. If it's only temporarily closed, opening_hours=closed seems fine. --Dafadllyn (talk) 18:15, 12 July 2021 (UTC)

opening_hours=closed isn't a good idea for the data update cycles. More importantly original opening_hours=* needs to be kept. ---- Kovposch (talk) 04:56, 13 July 2021 (UTC)

@Kovposch: If a restaurant or shop is closed for several months (e.g. due to renovations or illness of the proprietor), i think it makes sense to tag this somehow. Of course, the business in question should be checked regularily. disused:=* doesn't seem to be suitable for this. Besides, the old opening hours are always presevered in the history of the object. --Dafadllyn (talk) 19:14, 13 July 2021 (UTC)

Applications don't see the object history, nor necessarily support disused=yes on POI (it is only certainly useful on structures like building=*). For your case's the longer time period and the lack of support of temporary:*=*, at least you can add the date to opening_hours=* or something. ---- Kovposch (talk) 06:04, 14 July 2021 (UTC)

I know that applications don't see object history, but mappers do. And after a longer temporary closure, the opening hours should be checked anyway, as they may have changed. I also agree that disused=yes on a POI isn't a good idea (actually, if a pub is closed, the premises are disused, not the pub; thus it were more logical to use closed:*=* (prefix) for POIs and disused=yes for physical objects). I still think that e.g. amenity=pub + opening_hours=closed + description=temporarily closed due to renovation works + fixme=please check if open again is the best solution for temporarily closed POIs where it is unclear when they will reopen. --Dafadllyn (talk) 16:31, 14 July 2021 (UTC)

I don't know why would you refer to a random old question. disused=yes + amenity=* is frowned upon for "trolling". ---- Kovposch (talk) 04:56, 13 July 2021 (UTC)

opening_hours=none

Mention how to say opening_hours=none, pure and simple. —Preceding unsigned comment added by Jidanni (talk • contribs) 2023-05-02

@Jidanni: What would that mean? —M!dgard (talk) 20:40, 2 May 2023 (UTC)

Just like some places would be open 10 minutes a day, others 5 minutes a day, and then some zero minutes a day. Jidanni (talk) 22:50, 4 May 2023 (UTC)

You can use opening_hours=off for that. Or if the place is "not in use", change the primary tag to disused:*=*. —M!dgard (talk) 09:15, 5 May 2023 (UTC)

For a few hours after sunset until the batteries run out

How to format such solar lighting hours? Yes, daily. Jidanni (talk) 18:49, 27 October 2022 (UTC)

opening_hours=*-sunset+ open "Until battery drained" (open end is allowed on these special times as well) --- Kovposch (talk) 03:45, 28 October 2022 (UTC)

Advent (sunday) dates tagging

How can/should be tagged these dates? There is a former thread in the (de) forum, auto translate to (en). There was an proposed and uploaded solution as an example for the 3rd Advent (sunday):

 * Dec 11-Dec 17: Su 10:00-17:00
 :de: Am 3. Advent (der nicht vor dem 11. oder nach dem 17. stattfinden kann) von 10:00 bis 17:00 Uhr geöffnet. 
 :en: Open on the 3rd Advent (which cannot take place before the 11th or after the 17th) from 10:00 a.m. to 5:00 p.m.

This edit was reverted by this change and comment "this is not a correct example". @M!dgard: could please give some more details what was/is wrong with that, so there is maybe an option to improve this?--MalgiK (talk) 17:55, 20 November 2022 (UTC)

I don't remember. It looks correct, though arcane. —M!dgard (talk) 21:24, 20 November 2022 (UTC)

This reminds me of a largely academic thread on OSMUS Slack about how to tag a Lenten fish fry, which would be open Fridays during Lent other than Good Friday. In the U.S., Lenten fish fries at parish halls are very popular in predominantly Catholic cities but open so infrequently that I don't think people have been mapping them. However, there are some restaurants that change their cuisine on Fridays during Lent or have a special drive-through fish fry:

opening_hours=Tu-Th 09:00-15:00
opening_hours:drive_through=easter-44 days, easter-37 days, easter-30 days, easter-23 days, easter-16 days, easter-9 days 14:00+

OK, it's a little soon to be thinking about Easter. :^)

 – Minh Nguyễn ^💬 23:37, 20 November 2022 (UTC)

1st advent: Nov 27-Dec 03 Su
2nd advent: Dec 04-10 Su
3rd advent : Dec 11-17 Su
4th advent : Dec 18-24 Su Fabi2 (talk) 22:41, 18 December 2023 (UTC)

Summer/winter time?

Here in Montenegro opening hours of various shops often differ depending on whether it's summer or winter time; how to specify this? The signboards don't tell exact dates as demanded by the key syntax, and apparently the summer/winter thing refers to the pan-European DST schedule that looks horrific to specify. L29Ah (talk) 15:03, 24 November 2022 (UTC)

There's 33 uses of opening_hours:summer=* and 23 uses of opening_hours:winter=*. That would be my suggestion. I think it would be fine to leave out the exact dates if they are not on the signboards. --Adamant1 (talk) 13:43, 25 November 2022 (UTC)

I agree this is a good use of opening_hours:*=*. Otherwise the alternative is overloading opening_hours:conditional=* @ (winter). or maybe opening_hours:seasonal=* ???
The most backward-compatible method would be to give an approximate range with comments. Eg opening_hours=* open "Winter"; * open "Summer" (open needed for commented clauses) to ask applications and users to consider.
There was a discussion this week https://discord.com/channels/413070382636072960/782593988611014676/1045669449061109820
ISO 8601 uses "month" greater than 12 for seasons and other periods. start_date:edtf=* aims to support Level 1.
My usual complaint: Most of the opening_hours:*=* (they don't have that many uses anyway) should be reversed to *:opening_hours=* to follow the hierarchy of the sub-feature. Eg atm=*, drive_through=*, lifeguard=*. pharmacy=* has some uses too.
--- Kovposch (talk) 11:04, 26 November 2022 (UTC)

I've tagged seasonal restaurants with opening_hours:13:00-01:00; Nov-Mar off=*
--- beatnick 00:47, 08 Jan 2023 (UTC)

Maybe add early June, mid August, late October

Ravinia Farmers Market, Wednesdays from June 7 - October 25, 2023 [5].

Well instead of needing to edit this each year, have a new syntax with approximate parts of the month. Jidanni (talk) 15:42, 17 July 2023 (UTC)

2023 Jun 7-Oct 25 We 10:00-18:00 Fabi2 (talk) 22:30, 18 December 2023 (UTC)

Listed hours versus reality of being available 24/7

Parks in our area have posted hours (ex 8am to 9pm, or "Dawn to Dusk"). But because they are public parks, they are in practical terms "open" all of the time. Should I just not add an Hours tag, set the actual hours, or set the tag to "24/7"?

Thanks --TinyMapper (talk) 04:09, 11 December 2023 (UTC)

I would not add them, if these are legal fiction. Technically adding them is possible but just is going to be done for sake of lawyerish art Mateusz Konieczny (talk) 14:58, 11 December 2023 (UTC)