Opening hours syntax for non Gregorian calendar

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Opening hours syntax for non Gregorian calendar

Saeed Hubaishan
As I see in the wiki opening hours should be in Gregorian calendar only.  But in fact there are many countries and religions using another calendars that affect the opening hours.

We (Muslims) used the Hijri Calendar https://en.wikipedia.org/wiki/Islamic_calendar (lunar calendar)  for our holidays (Eid Alfiter and Eid Aledha)  all government offices and shops has another opening time in these holidays. Also in Ramdan holy month (9th month) all government offices and shops has a different opening time.

So opening_hours syntax must accept the other calendar systems.


the renderers may use ICU open source library to manage these other calendars see http://userguide.icu-project.org/datetime/calendar


الحصول على Outlook for Android


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Paul Allen
On Fri, 17 May 2019 at 19:42, Saeed Hubaishan <[hidden email]> wrote:

So opening_hours syntax must accept the other calendar systems.

Opening_hours syntax is complicated enough, without adding other calendar systems.  It
is a compromise between human readability and computer parseability.  Some would say it
is already too complicated, even though it doesn't handle some things that some people
would like it to.

I think that you would have to come up with something like opening_house:islamic or
something like that to segregate the two systems.

And that only handles dates.  Some Islamic countries use solar time rather than a time offset
from UTC.  Worse, different Islamic countries have slightly different definitions of solar time.
And then some places may use the solar time (defined one way) of a central location whilst
others use the solar time (possibly defined a different way) locally: one country might use
solar time in the capital city everywhere in the country whilst another uses the local solar time.
You can probably get away with saying "12:00 means noon in this locality, however they define
it" but maybe not.  "However the locals define it" is probably workable for tourists, not so good
for people who want to phone an office on the other side of the country before it closes.

It gets messy, but if you can come up with something that handles all the possibilities,
that's great.  But please put it in opening_hours: whatever_we_call_it rather than ordinary
opening_hours.  Because opening_hours is already messy enough.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Mateusz Konieczny-3



17 May 2019, 21:13 by [hidden email]:
On Fri, 17 May 2019 at 19:42, Saeed Hubaishan <[hidden email]> wrote:

So opening_hours syntax must accept the other calendar systems.

Opening_hours syntax is complicated enough, without adding other calendar systems.  It
is a compromise between human readability and computer parseability.  Some would say it
is already too complicated, even though it doesn't handle some things that some people
would like it to.

I think that you would have to come up with something like opening_house:islamic or
something like that to segregate the two systems.
I am not convinced that it would make it less messy - it just hides part of complexity by
moving it to a different tag.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Paul Allen
On Fri, 17 May 2019 at 21:19, Mateusz Konieczny <[hidden email]> wrote:

17 May 2019, 21:13 by [hidden email]:
I think that you would have to come up with something like opening_house:islamic or
something like that to segregate the two systems.
I am not convinced that it would make it less messy - it just hides part of complexity by
moving it to a different tag.

It  really would make it less messy.  It's not simply trying to sweep it under the carpet.  Some of
what we already have is hard for humans to understand.  Which is why we have syntax checkers,
but they have some disagreements in what they consider valid, so parsing it is hard, too.  Any
proposed extension to the current syntax, however small, has to be very carefully considered
in case it breaks things.  A large change such as throwing in a different calendar is pretty
much guaranteed to be almost incomprehensible to humans and impossible to parse.

Splitting it off into opening_hours:calendar minimises the problems caused by handling other
calendars.  It doesn't make the syntax for standard opening_hours more complex.  It also has
the very big advantage that if we later discover, or introduce, a serious flaw in the syntax for
calendar_X it won't have an effect on calendar_Y.  "Ooops, we really screwed up the Klingon
calendar, but at least all the other calendars are OK."  In other words, open up this can of worms
if you must, but I don't want any on my plate.

Problem of splitting: what if a mapper gives the opening times in both calendar_X and calendar_Y
and they disagree?  Consumers will have to have rules like: in country_Z use calendar_X if given,
otherwise use standard opening_hours if given, otherwise use calendar_Y if given, otherwise
pick at random from what is left.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Phake Nick
That doesn't seems to solve the problem that would occur. For instance, how to represent the first Sunday (a feature in Gregorian calendar) after Chinese traditional ceremony X (a feature in Chinese traditional calendar) in the opening time syntax, if they're split up for "simplicity"? What about when the opening time also cover non-holiday festivals that only occurs according to either calendars?

On 2019-05-18 Sat 04:50, Paul Allen <[hidden email]> wrote:
Problem of splitting: what if a mapper gives the opening times in both calendar_X and calendar_Y
and they disagree?  Consumers will have to have rules like: in country_Z use calendar_X if given,
otherwise use standard opening_hours if given, otherwise use calendar_Y if given, otherwise
pick at random from what is left.

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

SimonPoole


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.

Further expressing a rule is one thing, evaluating it is a something else, and adding some kind of "context" value to help in the later (for example a time zone value as has been suggested previously)  could potentially work.

Simon

Am 18.05.2019 um 12:34 schrieb Phake Nick:
That doesn't seems to solve the problem that would occur. For instance, how to represent the first Sunday (a feature in Gregorian calendar) after Chinese traditional ceremony X (a feature in Chinese traditional calendar) in the opening time syntax, if they're split up for "simplicity"? What about when the opening time also cover non-holiday festivals that only occurs according to either calendars?

On 2019-05-18 Sat 04:50, Paul Allen <[hidden email]> wrote:
Problem of splitting: what if a mapper gives the opening times in both calendar_X and calendar_Y
and they disagree?  Consumers will have to have rules like: in country_Z use calendar_X if given,
otherwise use standard opening_hours if given, otherwise use calendar_Y if given, otherwise
pick at random from what is left.

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Paul Allen
On Sat, 18 May 2019 at 12:01, Simon Poole <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

SimonPoole


Am 18.05.2019 um 15:28 schrieb Paul Allen:
...
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.
...

Evaluation of opening hours values already depends on location and lots of configuration for the PH tag (and in principle for the SH one too). So this wouldn't be introducing anything new. See https://github.com/opening-hours/opening_hours.js#holidays


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Saeed Hubaishan
In reply to this post by SimonPoole
Adding ramadan as <variable_date> is good.

I also  suggest adding optional [@calendar] to date range rules for non Gregorian dates and using month number instead of month abber name for example:

Sa-Th 09:00-21:00; 09/01-09/30 @hijri 20:00-03:00


الحصول على Outlook for Android


From: Simon Poole <[hidden email]>
Sent: Saturday, May 18, 2019 1:59:39 PM
To: [hidden email]
Subject: Re: [Tagging] Opening hours syntax for non Gregorian calendar
 


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.

Further expressing a rule is one thing, evaluating it is a something else, and adding some kind of "context" value to help in the later (for example a time zone value as has been suggested previously)  could potentially work.

Simon

Am 18.05.2019 um 12:34 schrieb Phake Nick:
That doesn't seems to solve the problem that would occur. For instance, how to represent the first Sunday (a feature in Gregorian calendar) after Chinese traditional ceremony X (a feature in Chinese traditional calendar) in the opening time syntax, if they're split up for "simplicity"? What about when the opening time also cover non-holiday festivals that only occurs according to either calendars?

On 2019-05-18 Sat 04:50, Paul Allen <[hidden email]> wrote:
Problem of splitting: what if a mapper gives the opening times in both calendar_X and calendar_Y
and they disagree?  Consumers will have to have rules like: in country_Z use calendar_X if given,
otherwise use standard opening_hours if given, otherwise use calendar_Y if given, otherwise
pick at random from what is left.

--
Paul

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

ebel
In reply to this post by Paul Allen
On 17/05/2019 21:13, Paul Allen wrote:
> I think that you would have to come up with something like
> opening_house:islamic or something like that to segregate the two
> systems.
There are some downsides to using a new `opening_hours:islamic` key:

  * What happens if there's an `opening_hours=*` and
`opening_hours:islamic=*` tag on the same object? And what if they are
correct?
  * Many OSM data consumers look at the `opening_hours` tag, and they
aren't aware of this new key.

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.

So I suggest just adding the opening hours that would make sense for a
local into the `opening_hours` tag, and follow the spirit of the
opening_hours syntax.

--
R/A/McC


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Paul Allen
On Wed, 22 May 2019 at 09:16, Rory McCann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

SimonPoole


Am 22.05.2019 um 14:31 schrieb Paul Allen:
..
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.
...


That is not really correct as written, OH has the concept of variable dates which are based on some external definition of when they exactly are, currently the only one defined is "easter".  Typically you would use these to start/end date ranges or a single date that is on or can be defined relative to such a date. So adding "ramadan" or any other, externally defined date of note is not really an issue as long as the string used doesn't conflict with anything else.

That is a separate concept from "PH" and "SH" which are just general references to public resp. school holidays (I suppose there might be a use case for "RH", religious holidays, but lets don't add baggage before somebody actually asks for it :-)).

Simon


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

ebel
In reply to this post by Paul Allen
On 22/05/2019 14:31, Paul Allen wrote:
> 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.

I'm not proposing that, I suggest we create a (short) list of accepted
calendar systems, and accepted abbreviations for each month in that
calendar. We don't have to expand it to all languages (you're right, it
would very impractical).

"Show in other languages" doesn't solve the problem of the months not
matching up.

> 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?).

I'd leave it up to people familiar with the area to come up with good
abbreviations. I'm sure they already have recognizable abbreviations.

`opening_hours` is machine readable, but it's also (mostly) human
readable. If you put islamic/etc months in it, and a tool doesn't
support that, it can just display the raw tag text to the user who will
probably be able to read it and know what the opening hours are! By
putting data in `opening_hours` (not `opening_hours:islamic`) and using
local appropriate names, we retain that benefit. It degrades gracefully.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Graeme Fitzpatrick
In reply to this post by SimonPoole


On Thu, 23 May 2019 at 00:10, Simon Poole <[hidden email]> wrote:

(I suppose there might be a use case for "RH", religious holidays, but lets don't add baggage before somebody actually asks for it :-)). 


But what are Christmas & Easter if they're not religious holidays? :-)

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Paul Allen
On Thu, 23 May 2019 at 00:06, Graeme Fitzpatrick <[hidden email]> wrote:

But what are Christmas & Easter if they're not religious holidays? :-)

Not all religious holidays are created equal.  Many cafes and restaurants in tourist areas are
closed on Christmas Day/Boxing day but are open on Good Friday/Easter Monday.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Philip Barnes
On Thursday, 23 May 2019, Paul Allen wrote:

> On Thu, 23 May 2019 at 00:06, Graeme Fitzpatrick <[hidden email]>
> wrote:
>
> >
> > But what are Christmas & Easter if they're not religious holidays? :-)
> >
>
> Not all religious holidays are created equal.  Many cafes and restaurants
> in tourist areas are
> closed on Christmas Day/Boxing day but are open on Good Friday/Easter
> Monday.
Easter Monday is not actually a religious holiday, its only the day off in-lieu of Easter Sunday being a none working day.

Good Friday in the Midlands at least is not equal, many businesses such as many factories are open and buses run a normal service. There are no buses here on a normal bank holiday Monday.

Phil (trigpoint)

--
Sent from my Sailfish device
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Andy Mabbett
In reply to this post by Paul Allen
On Wed, 22 May 2019 at 13:31, Paul Allen <[hidden email]> wrote:

> 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.
> opening_hours to keep things simple and to prevent a problem in one affecting all of them.

If only there was some sort of ISO standard for representing dates...

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Graeme Fitzpatrick


On Thu, 23 May 2019 at 22:27, Andy Mabbett <[hidden email]> wrote:

If only there was some sort of ISO standard for representing dates...

Yep, especially when you get those pesky Americans involved :-)

Is 5/6, the 5th of June or the 6th of May?

Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Kevin Kenny-3
In reply to this post by SimonPoole
On Wed, May 22, 2019 at 10:10 AM Simon Poole <[hidden email]> wrote:
> That is not really correct as written, OH has the concept of variable dates which are based on some external definition of when they exactly are, currently the only one defined is "easter".  Typically you would use these to start/end date ranges or a single date that is on or can be defined relative to such a date. So adding "ramadan" or any other, externally defined date of note is not really an issue as long as the string used doesn't conflict with anything else.

'easter' suffices for the entirety of the Christian calendar[1].  All
of the movable observances, from Septuagesima to Corpus Christi
(including well-known ones such as Ash Wednesday, Good Friday,
Ascension Thursday and Pentecost) are specified as a particular number
of days before or after Easter.

I'd be fine with adding such things as Ramadan, Eid al-Fitr, and
Muharram to the schema. Since it's easiest to consider fixed points of
the calendar, Hilal ar-Ramadan would most likely be the anchor point
for Laylat al-Qadr. Eid al-Fitr would have to be a separate point,
since it's determined by its own astronomical observation. (Ramadan
runs an extra day in most localities if clouds prevent the observation
of Hilal as-Shawwal.)

[1] Strictly speaking, the Feast of St Leander - a minor observance -
also is variable, observed on 27 February in common years and 28
February in leap years. This inconsistency arises because in the Roman
calendar, the days counted from the *end* of the month, and Leap Day
was done by repeating the _sextilis_ of February. (A leap year may
still be called a 'bissextile' year.) As far as I know, he's the only
saint on the modern calendar to have been martyred in the last five
days of February of a leap year. But I don't know of anything whose
opening hours are tied to the Feast of St. Leander. There's also a
complicated set of precedences and special cases for when movable
observances collide with fixed ones (e.g. what happens when Good
Friday falls on the Feast of the Annunciation), or when certain fixed
obervances fall on a Sunday, but I haven't heard any call to model
those, either.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Opening hours syntax for non Gregorian calendar

Phake Nick
In reply to this post by Paul Allen
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 <[hidden email]> 寫道:
On Wed, 22 May 2019 at 09:16, Rory McCann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12