Talk:Key:opening hours

From OpenStreetMap Wiki
Jump to: navigation, search

Comments

It would be interesting too for shops that open in rare hours. I prefer "key=Opening_Hours value=07,23" Nako 09:08, 29 April 2008 (UTC)

i agree. Sergionaranja 21:14, 29 April 2008

In the UK there is a rota system for local pharmacies to stay open late, so one shop does not always stay open late. If you go to a shop in the rota (maybe others too) there is a list in the window of which shop is open on each day. Chillly 10:14, 29 April 2008 (UTC)

this is one of the reasons i think taging that info is complex as it changes every week/month. who will update? Sergionaranja 21:16, 29 April 2008

There should be a possibility to enter opening hours to almost everything, that has opening-hours. Supermarkets and small convenience stores close in most countries at different times (even in the same city), in metropolitan areas there are often small shops open the whole night. Some pubs and fast-food-restaurants are open 24/7. I think this is a very important information if you are looking for a certain facility at night. Dieterdreist 12:51, 29 April 2008 (UTC)


I think opening hours tagging should be little more complex, because:

  • opening hours can start at any time, not only the whole hour
  • there could be lunch break
  • there could be different opening hours in different days of week
  • some facilities could be also open at saturdays, sundays etc.

But also tagging should be simple for simple cases. So I think Opening_Hours tag should allow more complex syntax, for example:

Opening_Hours = 24/7                   for non-stop facilities
Opening_Hours = Mo-Fr 8:30-20:00       open from 8:30 am to 8 p.m. every workday
Opening_Hours = Mo 10:00-12:00,12:30-15:00; Tu-Fr 8:00-12:00,12:30-15:00; Sa 8:00-12:00   complex opening hours

Vrabcak 13:18, 29 April 2008 (UTC)

ok Vrabcak, in this case how that info will be redered in the map or used ??. Sergionaranja 21:16, 29 April 2008
I think only 24/7 facilities should be visually different on basemap - with proposed symbols (small 24 number in the corner of the picture). More precise information could be given by some clickable overlay or could be used in navigation software for tasks such as: "show me nearest open bank". Vrabcak 12:45, 30 April 2008 (UTC)
for me your modifications for this proposal are ok. im going to keep the 24/7 format, as definitive to vote on. i think it will pass.
not so sure about the complex format, it goes further than i meant. probably i wouldn´t use it everywhere but i think can be usefull to some cases.
maybe we can split the vote.. Sergionaranja

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)

I like this proposal so far, it's equally good readable by humans and computers! What about special cases for certain days, like Mo-Fr it's open 8:00-18:00 but on Tu only 8:00-12:00? Can in such a case the specific day (Tu) be considered superior that the row of days (Mo-Fr) it's contained in? I also suggest the value Tu off. -- Fröstel 22:08, 5 May 2008 (UTC)

Interesting point you got here. the how to should be answered by coders programmers. in the syntax proposed so far will go as
opening_hours = Mo 8:00-18:00; Tu 8:00-12:00; We-Fr 8:00-18:00
or your way:
opening_hours = Mo-Fr 8:00-18:00; Tu 8:00-12:00 in wich last definition of days have a superior value and should be substracted from the previous.
We have to think here how this will be displayed to user?. on the other hand if this exception can be solved by the sintax so far, why not leave it and dont make too many rules that are harder to remember and more suitable for mistakes?--Sergionaranja 07:42, 6 May 2008 (UTC)
First of all I wouldn't make the superiority depentent on the location but make always single days superior to a row of days which include that day. Secondly I'd like to point out why I'm asking this. In germany that's a very common notation you'll find on almost every restaurant door: First giving hour for all days of the week, but then excluding the day off. This means also a German user will expect software to display opening hours in this notation. Further I believe that the syntax should be as close to reality as possible and when you look at it this doesn't make it seriously harder to parse for some software - there's worse in our main Data modell :-) Yesterday I've mapped two restaurants using this syntax. -- Fröstel 08:41, 6 May 2008 (UTC)
ok, im with you. also the Tu off can be used in different ways...
any other opinion on this ? --Sergionaranja 11:56, 6 May 2008 (UTC)
I don't like the Tu off option. If a shop is closed all day but previous entries would make it open, I suggest Tu 0:00-0:00, because it's logical / machine readable. How the opening hours is displayed (e.g. for German users) should be built in to the display software. What we should be trying to do here is make it easy to enter times and make it easy to build progressively more complex cases. -- OliverLondon 10:21, 9 May 2008 (UTC)

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 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 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)

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 didn't follow this because I know opening hours is a pain to code with all the possible exceptions ... I just did read the syntax and I think it's a mess : one example : it's closed all day : syntax is 'off' , it's open all day , syntax is '00:00-24:00' .... where is the logic ??

It's almost human readable but let's just say I want to show all the shops that are open 'now' (whenever the now is), this is gonna be tricky to code ... --PhilippeP 08:11, 28 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)

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
http://wiki.openstreetmap.org/index.php/Key:access
wich describes Access time restrictions:
date_on; date_off; day_on; day_off; hour_on; hour_off --Sergionaranja 09:46, 20 May 2008 (UTC)

Voting

from 2008-may-9 to 2008-may-17 is closed now


  • 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"

is closed

from 2008-may-17 to 2008-may-25

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"

is closed

from 2008-may-17 to 2008-may-25


subject of voting: apply opening_hours to ways Way

(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)

Sunrise / Sunset

There is a public park here, which is closed at sunset. I would be happy about a key for that. --Lulu-Ann 09:30, 4 August 2008 (UTC)

I am using opening_hours=sunrise to sunset for that. --Cartinus 13:37, 13 December 2009 (UTC)
Why "to"? Wouldn't opening_hours=sunrise-sunset be more consistent with other values such as opening_hours=8:00-18:00? --Tordanik 15:20, 13 December 2009 (UTC)
Because that is what I get if I translate what is on the sign from Dutch to English. --Cartinus 07:05, 14 December 2009 (UTC)
Ok. I'd still suggest a more consistent syntax, though. Otherwise evaluation gets really messy, and attempting to combine these with "normal" values (e.g. 12:00-sunset) wouldn't work easily, either. --Tordanik 19:46, 14 December 2009 (UTC)
Done --Cartinus 10:16, 20 December 2009 (UTC)

Parks often get opening hours like "sunrise minus 2 hours until sunset plus 2 hours" or just "sunrise - sunset". Could this be added to this tag? --Eimai 17:54, 8 November 2008 (UTC)

I'd support extending opening hours with something that can express this situation. Has anyone suggested a syntax for this already? --Tordanik 11:08, 1 September 2009 (UTC)
opening_hours=(sunrise+02:00)-(sunset-02:00) is currently used (in 16 values, [regex]: /\((?:dusk|sun|dawn)[^)]*(?:-|\+)[^)]*\)/). Although, Netzwolf has proposed and implemented a different syntax opening_hours=sunrise+02:00 hours-sunset-02:00 hours (used by 2 values, regex: /(?:dusk|sun|dawn).*hours/) to prevent errors when using it for Conditional restrictions. I am not sure what the better syntax would be, because the current syntax with the parenthesis is probably easier to read and could also be parsed. --Ypid (talk) 13:54, 1 September 2013 (UTC)

Dusk / Dawn

In the United States, it is not uncommon to see the allowed access time for a public park to be "closes at dusk" or "closed dusk to dawn". This value (dusk-dawn and dawn-dusk) would also be appropriate for light-detecting street and footway lamps, more appropriate, I think, than something like 'sunset plus 2 hours', for instance. --Ceyockey 02:28, 14 January 2010 (UTC)

I share your opinion so I implemented it during implementation of sunrise and sunset: Documentation. The syntax is the same as for sunrise,sunset: opening_hours=dawn-dusk or opening_hours=(dawn+00:30)-dusk. --Ypid (talk) 09:42, 21 September 2013 (UTC)
Which dawn and which dusk? Civil, nautical, or astronomical? I assume that in most cases this would mean civil dawn and dusk, right? -- DENelson83 (talk) 07:48, 3 October 2013 (UTC)
Civil (for dawn) and nautical (for dusk) I guess. Reference: SunCalc Documentation --Ypid (talk) 18:32, 4 October 2013 (UTC)
Unfortunately, most signs that give opening hours like that aren't more precise than "dawn" or "dusk" and there's no way to tell what exactly they mean, so I don't think the data in OSM can get more precise than the primary sources. --Tordanik 13:39, 5 October 2013 (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)

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. Icon wink.gif
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)

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)

Regular expression

I run the http://opening-times.co.uk site. I'd really like to integrate directly with OSM. I've had a good read through this thread and it seems really sensible.

I've been trying to work on a regular expression for extracting/validating opening_hours tags. Obviously this won't cover every case, nor should it, as opening times can be as complex as humans, however it should cover the vast majority of cases which will be helpful.

Here it is so far, please feel free to improve (tested in Ruby 1.8.7)

(?-mix:(?:(?:Mo|Tu|We|Th|Fr|Sa|Su)(?:-(?:Mo|Tu|We|Th|Fr|Sa|Su))? (?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off)(?:,(?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off))*)(?:; (?:(?:Mo|Tu|We|Th|Fr|Sa|Su)(?:-(?:Mo|Tu|We|Th|Fr|Sa|Su))? (?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off)(?:,(?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off))*))*(?:;? PH (?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off)(?:,(?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off))*)?(?:(?:; )?(?:(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d\d?|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d\d?-\d\d?|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d\d?-(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec) \d\d?|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)-(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))? (?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off)(?:,(?:[012]\d:[0-5]\d|off)-(?:[012]\d:[0-5]\d|off))*)?)

I've deliberately missed out exceptions as I think this will become complex for automatic tools to parse and also for humans to understand. I.e. If a shop is open longer on Thursday then I would expect this

Mo-We 09:00-17:00; Th 09:00-19:00; Fr-Sa 09:00-17:00

instead of

Mo-Sa 09:00-17:00; Th 09:00-19:00

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?

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)

seperate 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)

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)

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".

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

Osm element relation.svg 887209 (view, XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx)

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 really problem here that comes in the way is the restricted length of values of 255 characters in OSM. --Ypid (talk) 19:58, 27 August 2013 (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)

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)

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)

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)