在 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. 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. >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
