[Tagging] Opening hours syntax for non Gregorian calendar

[Paul Allen]

On Sat, 18 May 2019 at 12:01, Simon Poole <simon at poole.ch> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190518/26c9838e/attachment.html>