Taking into account the previous proposals (here and here), I've adapted Thryduulf's suggestion to create a new attempt at getting this much-needed information on Wikidata.
The advantage of using item-datatypes is that you can use non-numeric concepts like sunrise and sunset. Overall I think this proposal is very good, and Wikivoyage in particular should benefit from it.
Support I like it, although there is not a direct compatibility with Wikivoyage. A translator for that needs to be coded --★ → Airon 9007:17, 27 August 2020 (UTC)[reply]
Comment @NMaia: however what this does not allow is to model validFrom and validThrough, e.g. what if something is open from 8am-6pm from July 14th to September 8th? With this proposal we would have to have 365^2 items to model all possible combinations of days which is not really feasible. Maybe two more properties are needed for these edge cases ("open day" and "closing day"). This will often happen for seasonal outfits, such as Ski resorts. --Hannes Röst (talk) 16:09, 2 September 2020 (UTC)[reply]
What rush? This has been sitting around for four years. If there was any interest in the community to have an RfC held, it would have been done already. This, on the other hand, is a workable solution. NMaia (talk) 11:58, 27 August 2020 (UTC)[reply]
How is a property proposal not a "request for comments"? That's what we're doing here, this complaint smacks of needless bureaucracy. If you have specific prior art concerns then give us relevant links here. ArthurPSmith (talk) 17:27, 27 August 2020 (UTC)[reply]
No, its not an RfC, its a request for approval for a specific model. I've given examples of prior art - which this proposal ignores - in response to previous proposals for this property, to which I have referred above. If there is "needless bureaucracy", it is to keep expecting me to repeat them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:58, 20 September 2020 (UTC)[reply]
Oppose This ignores timezones. I oppose the usage of such annoying seconds items – either a Wikibase support for time and timezones or no opening hours. And for the more irregular opening hours the proposal does not clarify when open days (P3025) overrides a prior closed on (P3026) qualifier, i.e. when is it open and when closed given opening hours in this format. And lastly is there a way to say that no opening hours for public holiday (Q1197685) were specified, similar to the PH unknown in OSM opening hours syntax? --CamelCaseNick (talk) 14:05, 27 August 2020 (UTC)[reply]
Comment Wouldn't the timezone be implied to be the local one? I can't think of a situation where it would be something else. As for the seconds, I don't think any establishments actually have such precise hours, I was simply trying to show the flexibility of this system (but to avoid confusion, I'll amend the proposal). Regarding the unknown, if we editors don't know, what value is there in expressing it? It doesn't really help anyone. NMaia (talk) 16:49, 27 August 2020 (UTC)[reply]
Putting a timezone here would be a very bad idea. The item itself is already in a timezone, which is defined either in the item itself or in its located in the administrative territorial entity (P131) (recursive). Re-stating the timezone here would be a duplication of information, increase the burden of maintenance, and create vast amounts of stale data. Syced (talk) 04:45, 28 August 2020 (UTC)[reply]
Support This looks fine to me, using items should allow any edge case to be handled. If we need to specify timezones for some reason, we can create items for times with timezones, that doesn't seem to be a fundamental issue here. ArthurPSmith (talk) 17:26, 27 August 2020 (UTC)[reply]
Weak support Opening times would be a great addition. This proposal seems reasonable proposal even if I'm not sure if all normal edge cases can be handled. --Haansn08 (talk) 09:30, 1 September 2020 (UTC)[reply]
Weak supportSupport and time zone can always be added with located in time zone (P421) for cases where its unclear (or items without a geographical location). I think this should cover 99% of the cases. However, what about seasonal outfits where the start/end of the season may vary (see comment above)? --Hannes Röst (talk) 16:09, 2 September 2020 (UTC)[reply]
I think your proposal above sounds good but we might want to first make sure we actually have a use case for it within Wikidata. If we can find some 3 examples, I'm sold. NMaia (talk) 17:44, 2 September 2020 (UTC)[reply]
If start/end of the season varies every year, then realistically should we expect Wikidata to contain the exact date? For very notable places like Eiffel Tower (Q243) we could include each year's opening/closing time. For the rest, we could include opening/closing for summer (Q1313) and winter (Q1311) (or more local items such as winter in Sweden (Q18061850) or wet season (Q3117517)). As the previous comment says, would you mind finding 3 real-world examples of seasonal outfits where the start/end of the season may vary? Then we can see how well the structure fits. Thanks! :-) Syced (talk) 03:05, 3 September 2020 (UTC)[reply]
@NMaia: this is your proposal right? Syced seems to have interpreted your comment as suggesting we need 3 real-world examples here. I suppose that might be a good idea rather than these fictional ones... would you mind? Otherwise I would have marked this as ready to create. ArthurPSmith (talk) 17:09, 3 September 2020 (UTC)[reply]
@ArthurPSmith: Would one example be okay? These are really time-consuming to make and I think we all know they won't be much different. I'd rather spend that time adding the informations to the entries themselves. See below.
The "returning from lunch" sample with the same qualifier twice might make it difficult to calculate if a place is open at a given time. --- Jura20:04, 3 September 2020 (UTC)[reply]
When in a single day there are several different interval at which the place is open, how about using time interval (Q186081) for each of these intervals? Jura, you have a lot of experience, do you think that would work? It would make SPARQL queries easy to write, I believe. When there is only one interval, I would suggest skipping the time interval (Q186081), though. Screenshot of my sandbox experiment on the right (using dates instead of hours but the idea is the same). Syced (talk) 15:30, 4 September 2020 (UTC)[reply]
Probably the lunch break example should be done like this to be machine parseable:
Support Hours is a nice addition to the existing open days (P3025). I know it is obvious, but maybe mention that the hours are relative to the located in time zone (P421) value of the item itself or if none the first item that has one going up its located in the administrative territorial entity (P131) chain. Syced (talk) 05:12, 27 August 2020 (UTC)
Comment @NMaia: however what this does not allow is to model validFrom and validThrough, e.g. what if something is open from 8am-6pm from July 14th to September 8th? With this proposal we would have to have 365^2 items to model all possible combinations of days which is not really feasible. Maybe two more properties are needed for these edge cases ("open day" and "closing day"). This will often happen for seasonal outfits, such as Ski resorts. --Hannes Röst (talk) 16:09, 2 September 2020 (UTC)
Oppose This ignores timezones. I oppose the usage of such annoying seconds items – either a Wikibase support for time and timezones or no opening hours. 
Weak support Opening times would be a great addition. This proposal seems reasonable proposal even if I'm not sure if all normal edge cases can be handled. --Haansn08 (talk) 09:30, 1 September 2020 (UTC)
Done opening time (P8626) and closing time (P8627) Pamputt (talk) 05:36, 21 September 2020 (UTC)