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 <[email protected]> 寫道： > 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 >
_______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
