On Wed, 22 May 2019 at 09:16, Rory McCann <[email protected]> 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 [email protected] https://lists.openstreetmap.org/listinfo/tagging
