Of course such shop will also need to indicate the closing date in Gregorian calendar fashion, but as those date are not fixed, if you are typing that information in Gregorian calendar into OSM then you're effectively inputting one-off event into OSM that needs to be changed every year to match the calendar of the year.
在 2019年3月17日週日 01:57，Simon Poole <si...@poole.ch> 寫道： > > Am 14.03.2019 um 23:18 schrieb Phake Nick: > > > > 在 2019年3月14日週四 20:38，Simon Poole <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 > listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
