Gah, I had my filter for this mailing list misconfigured and so I just now saw this. So so so sorry.
I'll definitely do a RFC. Regarding issue (c), I'm obviously not familiar with internal PHP development processes, but is it usually the case that "You have X similar thing" is an argument for doing Y? Seems like there's no reason these decisions couldn't be made on an ad hoc basis--tabular calender is one thing because it's entirely self-contained, while other calendars would require access to an external data source that may disappear at any time, etc. On Sat, Sep 1, 2018 at 5:09 AM, Christoph M. Becker <[email protected]> wrote: > On 30.08.2018 at 22:33, Kurt Weber wrote: > >> The calendar conversion functions currently support (via Julian Day >> Numbers as an intermediary) conversion between Gregorian, Julian, >> Hebrew, and French Revolutionary calendars. Conspicuously absent is >> the Islamic calendar. A comment in ext/calendar/sdncal.h seems to >> suggest that the original author(s) intended to implement at some >> point, but never got around to it. >> >> The Islamic calendar offers some complications because in most >> places and communities that use it for religious purposes, the switch >> from one month to the next is based on actually observing the moon in >> the proper phase. In theory the date of this change can be >> calculated (and indeed the early Islamic surge in study of astronomy >> was motivated by the wish to know about when they should start >> looking), but tradition still demands that it be actually observed >> before a change is made--the actual impact of this is that local sky >> or weather conditions can sometimes interfere with the observation in >> a particular jurisdiction, meaning that often it comes a day or so >> later than when it otherwise would. >> >> Consequently, what I'm proposing is the Tabular Islamic Calendar, >> which was specifically created to be predictable and calculable. It >> is of limited use for religious purposes (and documentation should >> probably be clear about this), but it would be useful for, e.g. >> people working with historical documents from Islamic communities or >> groups (In fact, this is how I came to this problem--I am working on >> a Ph.D. in Russian history, and as a side project I'm developing a >> PHP-backed website to manage research notes and other information; >> because I work on prerevolutionary Russia I'm very familiar with the >> issue of needing to convert between calendar systems (in my case, >> Julian and Gregorian), and my colleagues working on Islamic history >> often have similar issues.). >> >> Tabular Islamic calendar is not ideal, but it seems like the only >> realistic option for automated conversion. >> >> As far as implementation goes, I could do it. I've already >> implemented conversion one way, before I stopped work in case there >> were issues that come up in this discussion that I hadn't foreseen >> (unfortunately, that happened roughly at the time the mailing list >> server seems to have died, so it's been paused for a couple of >> weeks). So all I'd have to do is the other direction, and it'd be >> ready to test. > > Thanks! I'm not opposed to this suggestion. There is the suspended > feature request #27453[1], and I agree that even a tabular Islamic > calendar would be much more useful than the French Revolunationary calendar. > > Presently, I see three counter-arguments: > > (a) already supported by ext/intl > (b) maintenance burden > (c) opening up a can of worms > > Ad (a): Islamic calendars are already supported by the > intl extension[2]. Even though ext/intl supports an Islamic calendar, > that doesn't prohibit that ext/calendar also does, though, since they > are independent extensions (cf. ext/mbstring, ext/iconv, ext/recode). > > Ad (b): if nobody else is willing to step up as maintainer of > ext/calendar[3], I'd be willing to do so. I've already did some > maintenance[4] so far. > > Ad (c): this is somewhat of a problem. I can easily imagine folks > requesting support for specific Islamic calendars which would require > (up-to-date) data, what could easily blow ext/calendar out of > proportion. Also I can imagine people coming up with “the FOO calendar > is used more widely than the tabular Islamic calendar, so it should be > supported as well” argument. > > Especially due to (c) I suggest to go through the RFC process[5], > whereby the RFC could also set some precendence/rules for potentially > further calendar systems (i.e. what ext/calendar may support, and what not). > > [1] <https://bugs.php.net/bug.php?id=27453> > [2] > <http://icu-project.org/apiref/icu4j/com/ibm/icu/util/IslamicCalendar.html> > [3] > <https://github.com/php/php-src/blob/7956722cfd96fdc244e9ed3dd13e162094be09cd/EXTENSIONS#L257> > [4] > <https://bugs.php.net/search.php?cmd=display&package_name[]=Calendar+related&direction=DESC&limit=30&assign=cmb&status=All&reorder_by=ts2> > [5] <https://wiki.php.net/rfc/howto> > > -- > Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
