Am 14.03.2019 um 23:18 schrieb Phake Nick: > > > 在 2019年3月14日週四 20:38,Simon Poole <si...@poole.ch > <mailto:si...@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging