fitnr / convertdate Goto Github PK

This condition: 'pytz >= 2014.10, <2016' in your setup.py config seems to break a complex setup, when other lib already depends on the last pytz version:

pkg_resources.ContextualVersionConflict: (pytz 2016.10 (.venv/lib/python2.7/site-packages), Requirement.parse('pytz<2016,>=2014.10'), set(['convertdate']))

Recent changes made by Travis have broken automatic tests. Travis has always been clunky, so this is a good time to migrate away.

I would like to add some additional Hebrew calendar holidays but I don't know how to initiate that. I wrote the code, but I don't know the process for initiating the feature and making the pull request.

def shemini_azeret(year, eve=None):
    year, month, day = hebrew.to_jd_gregorianyear(year, hebrew.TISHRI, 22)
    if eve:
        day = day - 1
    return year, month, day


def lag_baomer(year, eve=None):
    year, month, day = hebrew.to_jd_gregorianyear(year, hebrew.IYYAR, 18)
    if eve:
        day = day - 1
    return year, month, day


def tu_beshvat(year, eve=None):
    year, month, day = hebrew.to_jd_gregorianyear(year, hebrew.SHEVAT, 15)
    if eve:
        day = day - 1
    return year, month, day


def ninth_av(year, eve=None):
    year, month, day = hebrew.to_jd_gregorianyear(year, hebrew.AV, 9)
    if eve:
        day = day - 1
    return year, month, day
      

@property
    def tu_beshvat(self):
        return tu_beshvat(self.year, eve=False)

    @property
    def shemini_azeret(self):
        return shemini_azeret(self.year, eve=False)

    @property
    def lag_baomer(self):
        return lag_baomer(self.year, eve=False)

    @property
    def ninth_av(self):
        return ninth_av(self.year, eve=False)```

Just started looking at the convertdate and the very first example in the README file confused me because it shows that returned tuple contains four numbers:

french_republican.from_gregorian(2014, 10, 31)
# (223, 2, 1, 9)

When I installed it and tried to run this example I got sort of what I expected:

>>> french_republican.from_gregorian(2014, 10, 31)
(223.0, 2, 9)

Though floating point year is also a bit confusing. Is the year supposed to be an integer?

convertdate.julian.from_gregorian is incorrect for dates before January 23, 4717 BCE (Gregorian)

>>> convertdate.julian.from_gregorian(-4716, 1, 23)
(-4716, 3, 1)  # correct
>>> convertdate.julian.from_gregorian(-4716, 1, 22)
(-4715, 2, 31)  # wrong, February 31st
>>> convertdate.julian.from_gregorian(-4717, 1, 22)
(-4715, -8, -29)  # obviously wrong

After reading the code it looks like this is an intrinsic problem with the algorithm. Does convertdate not support dates before -4716? If so there should be a warning in the documentation.

edit: fixed the dates

Hello, a nice work you've done here!

I wanted to use this tool for our python-powered site and noticed that Adar months in leap year are not where they're supposed to be. The thing is that in Hebrew calendar Adar I is additional. I.e., a person born in Adar in a common Hebrew year would celebrate his birthday in Adar Bet (the second) in a leap year. Same thing with the Holidays.

So this way, hebrew.from_gregorian() should return consequently ... — 10 — 11 — 13 — 12— 1 — ... for a leap year. It might seem irrational, but this is the way Hebrew calendar works.

Since your package is on PyPI, I realize that this change will result in existing apps using this library not working properly when they update the library. But I assume nobody yet used it for Hebrew, because they would definitely notice the issue.

Although, I could make a pull request, but later, when I'm less busy.

https://en.wikipedia.org/wiki/Buddhist_calendar

I am getting strange results for the hebrew calendar if I use small years. Examples:

In [1]: hebrew.to_jd(1, 1, 1)
Out[1]: 348175.5

In [2]: hebrew.to_jd(1, 12, 30)
Out[2]: 348175.5

In [3]: hebrew.to_jd(1, 1, 1) == hebrew.to_jd(1, 12, 30)
Out[3]: True

In [4]: hebrew.to_jd(10, 1, 1) < hebrew.to_jd(10, 11, 12)
Out[4]: False

Is this a bug or a known limitation of this calendar implementation?

Hijri year before year 1 is year -1, not 0; the same behavior in the Gregorian calendar the year before 1CE is 1BCE.

I converted JD to Hijri Calendar with the following code:

from convertdate import islamic
# Example Julian day number
julian_day = 1948434  # Replace with your Julian day number
# Convert Julian day directly to Islamic (Hijri) date
hijri_year, hijri_month, hijri_day = islamic.from_jd(julian_day)
print(f"Hijri Date: {hijri_year}/{hijri_month}/{hijri_day}")

The output was:

Hijri Date: 0/12/25

While it should have been:

Hijri Date: -1/12/25

There are other utilities that when installed or updated will automatically get the latest pytz, which I think is 2018.3. This creates a dependency problem for convertdate. This is a request to be able to use the latest pytz version to remove conflicting dependencies between convertdate and other packages.

Kindest regards,
Tim

Today is the first day of Ayyám-i-Há, but when I run the following script:

import datetime
from convertdate import bahai

now = datetime.datetime.now()
bahai_date = bahai.from_gregorian(now.year, now.month, now.day)
print("Bahá'í Date: ", bahai_date)

I get the first day of the 19th month as a result:

Bahá'í Date:  (175, 19, 1)

Ayyám-i-Há is a period of intercalary days, and the 19th month should start after Ayyám-i-Há.
There are 19 months with 19 days, so 19*19=361, Ayyám-i-Há just fills the gap between 361 days and the total number of days depending on if it is a leap year or not.

holidays.py imports the Jewish months from hebrew.py but in the Yom Kippur calculation it refers to TISHRI instead of hebrew.TISHRI, causing a "not defined" error.

>>> convertdate.indian_civil.from_gregorian(-4713, 11, 26)
(-4791, 9, 5)
>>> convertdate.indian_civil.from_gregorian(-4713, 11, 25)
(-4791, 9, 4)
>>> convertdate.indian_civil.from_gregorian(-4713, 11, 24)
(-4791, 9, 4)  # same date twice

I think this may be related to the use of math.trunc instead of math.floor as corrected in fe9bc97. I haven't explored this myself yet

Hi,

I am using fbprophet 0.7.1 and holidays 0.10.3 but since Nov 8th I am getting an error when trying to add holidays from Israel.
In holidays it is used hebrew module from convertdate.

`When
30 # Passover
31 name = "Passover I"
---> 32 year, month, day = hebrew.to_jd_gregorianyear(year, hebrew.NISAN, 14)
33 passover_start_dt = date(year, month, day)
34 self[passover_start_dt] = name + ' - Eve'

TypeError: cannot unpack non-iterable float object`

¿Is this related to last convertdate 2.3 release of Nov 7th?

from_gregorian returns the wrong value for December 31st regardless of the year. The other days of the year seem to work fine.

>>>import convertdate
>>> convertdate.ordinal.from_gregorian(1, 12, 31)
(1, 0)
>>> convertdate.ordinal.from_gregorian(2, 12, 31)
(2, 0)
>>> convertdate.ordinal.from_gregorian(2, 12, 30)
(2, 364)
>>> convertdate.ordinal.from_gregorian(2020, 12, 31)
(2020, 0)
>>> convertdate.ordinal.from_gregorian(-200, 12, 31)
(-200, 0)

I'd be willing to right a patch but I'm unfamiliar with the equation used to find the ordinal. Can someone shed some light? I'd guess the problem is this line:

I just scanned the dependencies, and found that the Pymeeus package used by convertdate is licenced under the LGPL-3.0 License.

Is there a possible replacement we could make here?

Pymeeus Licence

Maybe this could be an alternative?
https://github.com/pavolgaj/AstroAlgorithms4Python

pytz version 2020.1 came out about on hour ago.

convertdate insists on pytz<2020

This will break many existing / new setups

Something similar happened already in #12

Perhaps chances are higher to break a virtualenv by limiting the upper version than by the fact, that pytz changes its API

from convertdate import hebrew
hebrew.monthcalendar(5782, 10)
[[1, 2, 3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13, 14], [15, 16, 17, 18, 19, 20, 21], [22, 23, 24, 25, 26, 27, 28], [29, None, None, None, None, None]]

Note that the last element, which is supposed to be a week, has only six elements instead of seven, like it does in other cases.
Have not yet tracked down the source of the problem.

I have an error when I try to get the last sunday of March 2019
I do

from convertdate import holidays,gregorian,utils
an = 2019
SUN = 6
MARS = 3
he = utils.nth_day_of_month(0, SUN, MARS, an)

and I get
he
(2019, 3, 24)

But the last sunday of march 2019 is the 31 and not the 24 !
How can I correct this problem.
Why that happens ?
Thank you.

Pascal

Title

>>> convertdate.islamic.from_jd(1948085.5)
(0, 1, 1)  # correct

>>> convertdate.islamic.from_jd(1948084.5)
(0, 0, 29)

There should be a warning in the documentation # wrong

Enhancement request: Please add Islamic holidays and Chinese New Year to holidays module. Here is a list of them: https://icalendars.net/religion/islamism/

The first month of civil year is Tishrei, and that is also when the year changes, so please add another method to return that method of month counting (Tishrei=1). This is also consistent with the Jewish calendar in Excel.

Per Wikipedia:

Nowadays, the day most commonly referred to as the "New Year" is 1 Tishrei (Rosh Hashanah, lit. "head of the year"), even though Tishrei is the seventh month of the ecclesiastical year. 1 Tishrei is the civil new year, and the date on which the year number advances. Tishrei marks the end of one agricultural year and the beginning of another,[31] and thus 1 Tishrei is considered the new year for most agriculture-related commandments, including Shmita, Yovel, Maaser Rishon, Maaser Sheni, and Maaser Ani.

The example listed in the README for Ayyám-i-Há gets the conversion to the Gregorian calendar a little wrong. The example is

bahai.to_gregorian(175, 19, 1)
# (2019, 2, 11)

but the correct conversion would be (2019, 2, 26). This is confirmed by looking at:

bahai.to_gregorian(175, 18, 19)
# (2019, 2, 25)

Which should be 1 day before the 1st of Ayyám-i-Há.

I have a PR for this, the fix is relatively straightforward...

• Washington's Birthday is celebrated on 3rd Monday, not a fixed 22nd (source).
• Other fixed US Federal holidays such as New Years, Veterans Day and Christmas are missing "observed" flag that moves them to a nearest weekday similar to one Independence Day implementation has.

I see you've uploaded a .whl, but for my needs (writing a Gentoo ebuild) I would like to have the tar.gz uploaded too.

You can use ./setup.py sdist upload or ./setup.py sdist and then use twine.

This is an Islamic calendar used in Saudi Arabia, and it gives dates that are sometimes a day offset from the Islamic calendar calculations in this library.
https://github.com/tytkal/python-hijiri-ummalqura

Please consider adding the the code that is used with (https://twitter.com/BabylonDate) to the repository.

Testing the code across different Python versions I found an odd difference between the same code running in Python2 vs. Python3:

$ python3
Python 3.8.2 (default, Apr 27 2020, 15:53:34)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import convertdate.hebrew
>>> convertdate.hebrew.to_jd(0, 1, 1)
347852.5

vs

$ python2
Python 2.7.14 (default, Sep 23 2017, 22:06:14)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import convertdate.hebrew
>>> convertdate.hebrew.to_jd(0, 1, 1)
347820.5

I think it only affects years before year 1. And I do not know which one is correct but would be nice to have them consistent.

I'd like to request support for the Human Era (or Holocene Era) calendar

Apologizes for the bombardment of issues, but i don't think julian.leap is doing what it's supposed to. The readme says the Julian calendar is proleptic before 4 CE, but the leap method always returns 3 for negative years, implying all BC years are leap years which I don't think is the intention.

I'm guessing the intended leap year function is:

def leap(year):
    return year % 4 == 0

However, julian.leap is used in julian.monthlength which is used in julian.legal_date which is used in julian.to_jd, so changing this leap year method could effect conversions. So does the leap method serve some other purpose I'm not aware?

It looks like converting from a Hebrew date and using that to search for a particular weekday is off by one.

Specifically, I ran the following test (based on 2.0.2), trying to find the first Saturday after the beginning of the Hebrew year. Note that 2014.09.28 is a Sunday, not a Saturday. Unless 6 isn't supposed to be Saturday, but according to the note in utils by search_weekday, Sunday is 0.

from convertdate import hebrew, gregorian, utils
hebrew.to_jd(5775,7,1)
2456925.5
shabbat = utils.next_weekday(6, hebrew.to_jd(5775,7,1))
shabbat
2456928.5
gregorian.from_jd(2456925.5)
(2014, 9, 25)
gregorian.from_jd(shabbat)
(2014, 9, 28)
gregorian.from_jd(2456928)
(2014, 9, 27)

Thanks!

Please add the Asgardian Calendar https://asgardia.space/en/calendar

Detailed information can be found here: https://asgardia.space/en/news/Asgardian-Calendar-updated

and on page 18/19 in this pdf: https://asgardia.space/storage/page/publication/attach/65/c6/65c6b5ad26f10de5f9539bb3422f77769e148c6130ff5a77d47a86c12d6dd433.pdf