[Tagging] Opening hours syntax for non Gregorian calendar

[Phake Nick]

then again, what about month numbering in Chinese calendar? There are no
month name, only lunar month 1, lunar month 2, etc.

在 2019年5月22日週三 20:33，Paul Allen <pla16021 at gmail.com> 寫道：

> 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
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190524/5f31efb7/attachment-0001.html>