Talk:Key:opening hours/Archive 1
Shop opening hours
(Old discussion from 2008) 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
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)
Rota system for pharmacies
(Old discussion from 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
More complex tagging
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
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)
- 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)
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)
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)
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
- Parsing such a syntax with pure regular expressions is pretty hard core … Maybe you can create a wrapper around opening_hours.js for Ruby. (I also use regex of course, but with a bit more control structure. See the tokenize function) --Ypid (talk) 10:37, 21 August 2014 (UTC)
Some people add "opening_hours=" in values box
We *MUST* fix documentation (as soon as possible) because people considering that "opening_hours=" should be added in value box!
Please search value opening_hours= here Now we have 271 values in the database with "opening_hours=" value at the beggining.
--Gutsycat (talk) 08:40, 1 November 2015 (UTC)
- Oh boy … The opening_hours="Example" thing is a wiki template. I had this issue previously … OSM key appears in value as well. Added note in English and German but the best way to fix this is to validate opening_hours in all editors (JOSM does it already). --Ypid (talk) 10:39, 1 November 2015 (UTC)
- Problem has been fixed in all language versions of the wiki for Key:opening_hours.--Ypid (talk) 21:14, 3 November 2015 (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)
- 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)
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)
- Civil (for dawn) and nautical (for dusk) I guess. Reference: SunCalc Documentation --Ypid (talk) 18:32, 4 October 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)