[Tagging] Opening hours syntax for non Gregorian calendar

[Paul Allen]

On Wed, 22 May 2019 at 09:16, Rory McCann <rory at technomancy.org> wrote:

>
> I don't know much about the islamic calendar. Could you give some
> examples of what data you'd like to enter? Most "opening hours" don't
> need to include years, so is that a problem? You could just use the
> islamic calendar month names if needed.
>

The problem with that is the same problem as allowing every language on the
planet to
use their own abbreviations for month names.  Only worse.

For better or worse, we standardized on three-letter abbreviations for
English month names.  We
couldn't have gotten away with one- or two-letter abbreviations because
then there would have been
collisions: "M" could be March or May, "Ma" could be March or May, etc.
Allow abbreviations in
other languages using the Latin alphabet and you get collisions even with
three-letter
abbreviations.  So we use English abbreviations, applications are free to
translate them
into the user's own language.

The problem is possibly fixable by switching to month numbering.  It
doesn't make the translation
aspect much easier since most modern programming languages can handle
hashes (aka
dictionaries, aka associative arrays) so there's no gain there.  It makes
human comprehension
harder, because many people have difficulty mentally translating month 8 to
August, so there's
a disadvantage there (for those with English as a first language; for
others it would probably
be an advantage.  It would require editor support (not impossible) and a
mass edit of
the database (not impossible, especially as there's a guaranteed one-to-one
correspondence).
I don't see OSM making the switch to numeric months, because it's a lot of
change for little
gain, but I could be wrong.

Now we throw in the Islamic calendar.  Which is luni-solar.  It's based
around the phases of the
moon, and there is not a one-to-one correspondence you get between, say,
December and the
Welsh Rhagfyr.   In the Islamic calendar, each month can be 29 or 30 days
long, depending upon
the visibility of the moon.  Except for the Shia Ismali Muslims, where
odd-numbered months have
30 days and even months have 29 days.  I've neglected leap year handling
for simplicity.  Then
there's the Judaic calendar, which is similar in some ways to the Shia
Islamic one, except it
is prone to fiddling month lengths to avoid holy days falling on certain
days of the week.

Is this a real problem?  MARchesvan in the Judaic calendar is a collision
with MARch, so we'd
have to switch to 6-letter abbreviations.  The Islamic calendar has
Rabi-Al-Awwal and
Rabi-Al-Thani; Jumada-Al-Awwal and Jumada-Al-Thani; Zul-Qaadah and
Zul-Hijjah, so that
would need some though (are RAA, RAT, JAA, JAT, ZUQ ZUH acceptable?).  Or
we switch to
month numbers, remembering that Julian month 6 is not Islamic month 6 or
Judaic month 6
and that Shia Islamic month 6 isn't (quite) Judaic month 6 and that you
have no idea which
calendar is in use, just that it's month 6 in some unspecified calendar.

There are other calendar systems out there.  Parts of the world still use
the Julian calendar,
which is currently 13 days ahead of the Gregorian calendar.

As others have pointed out, we might be able to accommodate holidays.
Although we're likely
to end up with collisions in the two-character namespace we currently allow
for them.  Feasible,
maybe.  Month names are something that isn't feasible without namespacing
opening_hours.

Oh, and then there's the fact that days start at midnight in the Gregoran
calendar but start at
sundown in Islamic and Judaic calendars.  And some countries are on solar
time, which
can be up to 14 minutes behind or 16 minutes ahead of local mean time.
Right now we
assume that times are in the local timezone and that the timezone is offset
by a known amount
(usually a multiple of one hour, sometimes a multiple of 30 minutes or even
a multiiple of
15 minutes) from UTC, not that local time drifts around.  If people want to
specify times as
solar time, because that's what their country uses, we again need to
namespace
opening_hours.

And don't forget that whatever we come up with has to work in conditional
statements.  So we
can have major changes to opening_hours that will require support in
editors and applications
and will probably have problems that we only discover down the line or we
namespace the
opening_hours to keep things simple and to prevent a problem in one
affecting all of them.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190522/e976b2be/attachment.html>