On Sat, 18 May 2019 at 12:01, Simon Poole <[email protected]> wrote: > > As I've pointed out before the one thing that is unproblematic to add are > more variable date public holidays, right now there is only easter > defined, adding ramadan for example would be no problem. >
Syntactically, probably not a problem. Calculation of the astronomical events is well-defined. Interpreting those events is not: In some schools of Islam, calculation suffices; in others visual confirmation is required. The two can (and often do) differ by a day. Possibly solvable by having ramadan_x and ramadan_y. Or just by ignoring the problem and stating that "ramadan" means local definition of Ramadan, whatever that happens to be. Note also that whilst opening_hours blithely defines "easter," the date on which it falls differs between the Catholic and Orthodox churches. When a country celebrates Easter depends upon religious factors. Can we just ignore the problem? For Easter, maybe. Data consumers could build in country-specific rules defining if Easter is Orthodox or Catholic. Along with astronomical calculations, that would allow an app to say "This office in a different country from you is closed because it follows a different definition of Easter from your location." Not so easy for Ramadan defined by visual observation. A bigger problem, as I see it, is that cultures using the luni-solar calendar often have days of the week that begin at sunset, not midnight. Especially important in religious observances: the Jewish Sabbath starts at sunset on Friday. In the current scheme, "Su off" is not strictly necessary (it can be inferred) but to be fair to other cultures you'll need to be able to specify Sabbath (the obvious abbreviation has a clash) and similar days in other cultures. These are just the problems I know of. I doubt that is all of them. -- Paul
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
