Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] Proposal: Add tabular Islamic calendar to calendar conversion functions

Posted by Kurt Weber 
Hi, everyone.

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.

--Kurt Weber

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hi,

On Fri, Aug 31, 2018, 3:33 AM Kurt Weber <[email protected]> wrote:

> Hi, everyone.
>
> 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.


I am not sure if that covers your need, maybe yes. intl supports the
islamic calendar using '[email protected]=islamic', f.e., as the first
parameter to IntlDateFormatter constructor.

best,
--
Pierre
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
Sorry, only registered users may post in this forum.

Click here to login