[Tagging] Expand the key:opening_hours

Phake Nick c933103 at gmail.com
Thu Mar 14 22:18:41 UTC 2019

在 2019年3月14日週四 20:38,Simon Poole <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.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190315/91bc3ccb/attachment-0001.html>

More information about the Tagging mailing list