[Tagging] Expand the key:opening_hours

[Simon Poole]

Am 14.03.2019 um 23:18 schrieb Phake Nick:
>
>
> 在 2019年3月14日週四 20:38，Simon Poole <simon at poole.ch
> <mailto:simon at poole.ch>> 寫道：
>
>     Some more comments:
>
>     - the OH values are currently always evaluated in the local time zone
>     (or to go even a bit further in a local context as the location they
>     apply to is always known), so a time zone indicator would be only
>     needed
>     in the cases that require different processing, the question is if
>     that
>     is common enough to justify the additional complication.
>
> The three most prominent area that are still using the calendar
> nowadays are China, Korea, Vietnam. Each of them have their own
> version of this lunar calendar with the most notable difference being
> the meridian used to create the calendar. So that once in a few years
> you could see reports saying that the lunar calendar and the festival
> that depends on it are not correct on some software.
>
> Let's say you represent the Lunar New Year as L01 01. The software can
> assume it mean Chinese New Year in China, Vietnamese New Year in
> Vietnam, and Korean New Year in Korea. So far so good. But then these
> festivals aren't just celebrated within these three countries. Places
> like Thailand, Indonesia, Japan, Australia, America, and many other
> countries around the world all have different events that would take
> place for the Lunar New Year. Sometimes they're commercial events that
> are currently catering specifically to Chinese New Year. Sometimes
> they are diaspora population that celebrate the festival on the same
> day as their parent countries. You cannot know which exact day it's
> referring to without referring to the timezone being used to calculate
> the calendar, and at least it need to specify
> Korean/Chinese/Vietnamese version and that is assuming the region will
> not create any new timezone in the future, like how time changes
> related to the Vietnamese war caused the North Vietnam and South
> Vietnam celebrated the new year at different date back then and
> resulted in some military advantages.

That's all fine and dandy, but the OSM opening_hours tags is for the
opening hours of facilities and similar, not a general purpose event
description facility. So I would expect that a shop in AUS that is
closed on a Chinese holiday to indicate that in a local Gregorian
calendar fashion.

>
> One might think it'd be easier to add CNY/KNY/VNY into the variable
> holiday separately like easter instead, but there are a number of
> other events that're celebrated based on local lunar calendar and is
> celebrated at more places than those aforementioned countries, like
> Confucius birthday, mid-autumn festival, double nine festival, and so
> on. If calendar-specific version of all these holidays are all getting
> their own values as variable-holiday then there would be too many of them.
>
> And there also other scenario that timezone value is useful, for
> instance iirc Fiji decided that the country will implement DST but the
> school system operation time will not follow the transition. Or in
> places like Xinjiang or West Bank where there are two different
> timezones used by different population living in same area.
>
>
>     - Summer and winter solstice can be, as far as I can see, modelled as
>     additional variable_date values (currently only "easter" is
>     defined), I
>     would avoid qualifying them with months as again, that require parser
>     changes that will cause issues.
>
>
> Except other solar terms are still used. For example March equinox and
> September equinox are national holiday in Japan. Setsubun celebration
> in Japan is mainly a day before first solar term in February but also
> a day before first solar term in May, August, November. Qing Ming
> (mainly China, Korea, etc.) is the first solar term in April.
>
>
>     - Lunar months: are there any common names for these instead of just
>     numbering? And how are the "leap" variants supposed to be different?
>
>     Simon
>
>
> It is usually just numbering, but in Chinese there are nickname for
> the 11th and 12th month, while in Japanese there are nickname for all
> the months. Consider that those nick name are less popular,
> regional-specific and language-specific, it seems like it would be a
> bad idea to name them after the months.
> The "leap" version are for when a year have 13 lunar months. Instead
> of naming the additional month the 13th month, various criteria are
> used to select one of those thirteen months, and then name it as the
> "leap" version of the previous month. There are on average about 7
> years with leap month in every 19 years.
>
>
The whole reason that the OH spec is such a mess is because it tries to
remain human readable (for non-nerds), I doubt that there is any support
for suddenly departing from that. A OH evaluator needs to have the logic
for determining if it is a leap year or whatever, the OH grammar simply
needs to define strings which correspond to the commonly used month names.

Simon



> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190316/a49a37ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190316/a49a37ed/attachment.sig>