In the Bulgarian community, we had a brief discussion on how to deal with shops and other PoI that display different opening hours for summer and winter, without being clear from the display what “summer” and “winter” actually mean (on which dates the seasons mentioned start and end). We seem to have reach consensus that we should tag such somewhat vague opening hours, but not try to guess ourselves what the mentioned seasons mean. Doing this means the tagged opening hours will not be 100% machine readable, but they can be human-readable. This is the problem of the shop/PoI, and we should leave it to data consumers to decide whether they want to interpret this more specifically or also leave it vague.
My questions here are:
Does the international community agree that we should just enter summer and winter opening hours, without interpreting ourselves what “summer” and “winter” mean exactly?
If so, how to tag this? Could we allow strings such as Sum and Win (and other season indicators as needed) in the tag value just like we allow Dec to indicate the month of December? Or could we introduce seasonal suffixes (or prefixes?) such as opening_hours:winter & opening_hours:summer as @Dimitar155 proposed (and document it)? These tag values will not be machine readable (software will not be able to determine if a shop is open at any date and time, if the change from winter to summer opening hours is not given by the shop) but software could present it in a human-readable form by translating Sum and Win to the language of the map user.
There’s absolutely no need to use conditional for seasonal variations in opening hours, which can already be described in the opening hours format if the switchover was known.
Any data consumers that can successfully handle @ summer would already be functionally using a date range.
Probably what is most appropriate is to enter a guess as to when the seasonal switchover is, and add a fixme:opening_hours=*
I don’t like guessing the seasonal switchover dates and adding a fixme. If an app displays separate opening hours for different seasons, I would be a bit disappointed at the lack of a specific date, but not as disappointed as finding out the date was wrongly guessed when I arrive at a POI.
Further, even when POIs have regularly-scheduled changes in opening hours, the precise dates may change from year-to-year. For something like a summer session at a university, ideally a local mapper would read the newly released calendar each year and fix each POI on campus, but simply saying “in summer, …” is typically sufficient for any local to know what to expect and presents a much lower maintenance burden.
Spr, Sum, Aut, Win seem ideal to me, but the new keys might be better for compatibility.
So instead of opening_hours=Summer 08:30-21:30; Winter 08:30-19:30 we could tag opening_hours=08:30-19:30 + opening_hours:conditional=19:30-21:30 @ summer. In this way data consumers that don’t understand summer can still deduce that between 8.30-19.30, the shop is always open. Between 19.30-21.30 in summer it will deduce that it is closed while it is actually open, but that’s not a large part of the possible opening hours range. A data consumer could present a text to the map user that between 19.30-21.30 in summer, the shop is open (machine-translating summer in the language of the map user). At Key:maxspeed:conditional - OpenStreetMap Wiki it is mentioned that there is already a precedent for summer and winter speed limits in Finland.
I don’t like that either because the most likely correct guess is influenced by culture. It might be astronomical or meteorological summer/winter, start/end of daylight saving time, or weather dependent (siesta closure or late evening opening only when it’s too hot to go out shopping in the middle of the day, reduced opening during monsoon, etc.).
I think tagging an opening hours that would be wrong half of the year is not a good idea for the same reason JuanElDemografo said.
I say use opening_hours:conditional and either leave opening_hours blank or use comments like “in summer” to make it clear to software that the tagged opening hours are not to be relied on.
my idea would be motivated by having a fallback so data consumers unable to do this (more or less all of them) would still be able to handle it at least partially
But putting it in opening_hours= makes opening_hours= more complicated. Furthermore *:conditional= has other potential uses, eg =* @ (wet) , =* @ (snow) , which could simplify or make parsable the comments.
The solution in current syntax is opening_hours=Mo-Fr 10:00-22:00 "summer"; Mo-Fr 11:00-18:00 "winter" or opening_hours=Mo-Fr 11:00-18:00 || Mo-Fr 10:00-22:00 "summer"
opening_hours=Sum Mo-Fr 10:00-22:00; Win Mo-Fr 11:00-18:00 could be an improvement, but this seems limited: essentially it remains vague, as the definition of “summer” (and “winter”) can vary.
Depending on the place, maybe opening_hours=Aug Mo-Fr 10:00-22:00; Jan Mo-Fr 11:00-18:00; Mo-Fr 10:00-22:00 "summer", Mo-Fr 11:00-18:00 "winter" could be an improvement.
=Mo-Fr 10:00-22:00 "summer"; Mo-Fr 11:00-18:00 "winter" is wrong. The rule after semicolon overwrites the previous. Only the 2nd one using fallback is correct.
It’s fine to make a best guess =Mo-Fr 11:00-18:00, Apr-Sep Mo-Fr 10:00-22:00 "Open in summer"