fitnr / convertdate Goto Github PK
View Code? Open in Web Editor NEWUtils for converting between date formats and calculating holidays
License: MIT License
Utils for converting between date formats and calculating holidays
License: MIT License
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...
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.
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.
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?
I'd like to request support for the Human Era (or Holocene Era) calendar
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!
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)```
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?
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
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']))
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
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
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?
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.
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
>>> 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
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.
Recent changes made by Travis have broken automatic tests. Travis has always been clunky, so this is a good time to migrate away.
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
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
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?
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?
Please consider adding the the code that is used with (https://twitter.com/BabylonDate) to the repository.
BUILDSTDERR: Traceback (most recent call last):
BUILDSTDERR: File "setup.py", line 13, in <module>
BUILDSTDERR: readme = open('README.rst').read()
BUILDSTDERR: File "/usr/lib64/python3.4/encodings/ascii.py", line 26, in decode
BUILDSTDERR: return codecs.ascii_decode(input, self.errors)[0]
BUILDSTDERR: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 89: ordinal not in range(128)
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.
Enhancement request: Please add Islamic holidays and Chinese New Year to holidays module. Here is a list of them: https://icalendars.net/religion/islamism/
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
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:
convertdate/src/convertdate/ordinal.py
Line 34 in 001033c
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.