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
hi,
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 'en_EN@calendar=islamic', f.e., as the first
parameter to IntlDateFormatter constructor.
best,
Pierre
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
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.
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 wormsAd (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
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.
Great! I you have not already, you can register as Wiki user via
https://wiki.php.net/rfc?do=register. Please send a notice regarding
your user name, so that one of the Wiki admins can grant you RFC karma.
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.
Yes, if in doubt these decisions will be made on a case-by-case basis,
but I think it's useful to add the argument about not needing any
external data source to the RFC.
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 wormsAd (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