https://en.wikipedia.org/wiki/ISO_8601#Durations

See the following snippet:

>>> s = "P12YT0H0M"
>>> str(isodate.parse_duration(s))
'12 years, 0:00:00'
>>> isodate.parse_duration(s).total_seconds()
0.0

The library incorrectly places the larger increments in the object, as can be seen here:

>>> isodate.parse_duration(s)
isodate.duration.Duration(0, 0, 0, years=12, months=0)

While in code here: https://github.com/gweis/isodate/blob/master/src/isodate/isoduration.py#L92 it is actually clear that the author chose to output another other format when a year or months is sent, but I argue this behaviour is wrong.

• When the input (you never know!) changes the output format suddenly changes; Surprise!! ;-(
• This change of output format is hidden, because .total_seconds() still works fine, but the conversion is wrong!!
• There is no apparent benefit of keeping the Duration type. You could always convert a timedelta object back to something pretty if you want.

TL;DR I suggest always converting to timedelta.

Also move testing from Travis CI to GitHub Actions

• also allows testing on macOS and Windows
• 20 parallel jobs instead of 4
• Travis CI has an uncertain OSS future
• For example: https://github.com/hugovk/isodate/actions/runs/775454949

Move coverage from Coveralls to Codecov

• For example: https://app.codecov.io/gh/hugovk/isodate/

Run Flake8 via pre-commit

• Pins versions
• Makes it easy to run on CI and as optional pre-commit hook
• Add some other handy pre-commit fixers/linters too

Here's the pip installs for isodate from PyPI for March 2021, showing low numbers for EOL versions:

| category | percent | downloads | |----------|--------:|-----------:| | 3.7 | 51.39% | 16,518,933 | | 3.6 | 25.40% | 8,165,006 | | 3.8 | 10.28% | 3,305,128 | | 3.5 | 4.76% | 1,529,899 | | 2.7 | 3.16% | 1,016,819 | | null | 3.06% | 982,390 | | 3.9 | 1.92% | 617,791 | | 3.4 | 0.03% | 10,536 | | 3.10 | 0.00% | 540 | | 3.3 | 0.00% | 15 | | 2.6 | 0.00% | 13 | | Total | | 32,147,070 |

Date range: 2021-03-01 - 2021-03-31

Source: pip install -U pypistats && pypistats python_minor isodate --last-month

Closes: #71, Ref: https://github.com/gweis/isodate/pull/66#issuecomment-992006703

$ pre-commit run --all
pyupgrade................................................................Passed
flake8...................................................................Passed
check blanket noqa.......................................................Passed
Check for merge conflicts................................................Passed
Check Yaml...............................................................Passed
Fix End of Files.........................................................Passed
Trim Trailing Whitespace.................................................Passed
black....................................................................Passed
isort....................................................................Passed
mypy.....................................................................Passed

+ PYTHONPATH=/home/tkloczko/rpmbuild/BUILDROOT/python-isodate-0.6.0-8.fc35.x86_64/usr/lib64/python3.8/site-packages:/home/tkloczko/rpmbuild/BUILDROOT/python-isodate-0.6.0-8.fc35.x86_64/usr/lib/python3.8/site-packages
+ /usr/bin/python3 -Bm pytest -ra
=========================================================================== test session starts ============================================================================
platform linux -- Python 3.8.9, pytest-6.2.3, py-1.10.0, pluggy-0.13.1
rootdir: /home/tkloczko/rpmbuild/BUILD/isodate-0.6.0
plugins: forked-1.3.0, shutil-1.7.0, virtualenv-1.7.0, asyncio-0.14.0, expect-1.1.0, cov-2.11.1, mock-3.5.1, httpbin-1.0.0, xdist-2.2.1, flake8-1.0.7, timeout-1.4.2, betamax-0.8.1, pyfakefs-4.4.0, freezegun-0.4.2, flaky-3.7.0, cases-3.4.6, hypothesis-6.10.0
collected 18 items

src/isodate/tests/test_date.py .                                                                                                                                     [  5%]
src/isodate/tests/test_datetime.py .                                                                                                                                 [ 11%]
src/isodate/tests/test_duration.py ..........                                                                                                                        [ 66%]
src/isodate/tests/test_pickle.py ....                                                                                                                                [ 88%]
src/isodate/tests/test_strf.py .                                                                                                                                     [ 94%]
src/isodate/tests/test_time.py .                                                                                                                                     [100%]

============================================================================= warnings summary =============================================================================
src/isodate/tests/test_duration.py: 18 warnings
  /home/tkloczko/rpmbuild/BUILD/isodate-0.6.0/src/isodate/duration.py:183: DeprecationWarning: an integer is required (got type decimal.Decimal).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
    newdt = other.replace(year=newyear, month=newmonth, day=newday)

-- Docs: https://docs.pytest.org/en/stable/warnings.html
===================================================================== 18 passed, 18 warnings in 0.12s ======================================================================

Fixes https://github.com/gweis/isodate/issues/58. Fixes https://github.com/gweis/isodate/issues/67.

Python 3.10 is due out on 2021-10-04, three weeks from now.

https://discuss.python.org/t/python-3-10-0rc2-is-now-available/10496?u=hugovk

This deprecation warning was added in Python 3.8:

DeprecationWarning: an integer is required (got type decimal.Decimal). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.

For example:

Python 3.8.6 (v3.8.6:db455296be, Sep 23 2020, 13:31:39)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from isodate import Duration
>>> dt.date(2000, 3, 30) + Duration(days=1)
/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/isodate/duration.py:183: DeprecationWarning: an integer is required (got type decimal.Decimal).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
  newdt = other.replace(year=newyear, month=newmonth, day=newday)
/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/isodate/duration.py:183: DeprecationWarning: an integer is required (got type decimal.Decimal).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
  newdt = other.replace(year=newyear, month=newmonth, day=newday)
datetime.date(2000, 3, 31)
>>>

https://bugs.python.org/issue36048

In Python 3.10 it is now an error:

TypeError: 'decimal.Decimal' object cannot be interpreted as an integer

For example:

Python 3.10.0rc2+ (heads/3.10:a272ffe, Sep  8 2021, 11:20:24) [Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime as dt
>>> from isodate import Duration
>>> dt.date(2000, 3, 30) + Duration(days=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/hugo/.pyenv/versions/3.10-dev/lib/python3.10/site-packages/isodate/duration.py", line 183, in __add__
    newdt = other.replace(year=newyear, month=newmonth, day=newday)
TypeError: 'decimal.Decimal' object cannot be interpreted as an integer
>>>

https://bugs.python.org/issue37999

Failing build without fix:

• https://github.com/hugovk/isodate/runs/3584919810?check_suite_focus=true

Passing build with fix:

• https://github.com/hugovk/isodate/runs/3585342875?check_suite_focus=true

isodate is downloaded from PyPI 33 million times a month, the 52nd most popular package (https://hugovk.github.io/top-pypi-packages/), therefore I recommend making a release before 2021-10-04.

This PR also switches from Travis CI to GitHub Actions and Coveralls to Codecov, taken from https://github.com/gweis/isodate/pull/66, because testing on Travis CI is more difficult now. It only adds testing for supported Python versions. Let me know if this commit should be dropped, but I'd recommend merging #66 as well.

This will allow isodate to support addition and substraction with arrow objects.

Currently, the __radd__ and __rsub__ methods are pending on crsmithdev/arrow#344, as arrow currently raises TypeError instead of returning NotImplemented (which results into python not looking at isodate's methods for that).

isodate suffers from the same issue (rasing TypeError instead of returning NotImplemented). This however won't affect the behaviour with arrow objects, so I'll address this in another PR.

Rounding of fractional seconds breaks when it rounds to 60. (Presumably true for other fractions)

isodate.parse('9999-12-31T23.59.59.9999999') <- DateTime.Max from MS .NET

Example: Python 3.7.3 (default, Jan 22 2021, 20:04:44)

>>> import isodate
>>> isodate.parse_datetime('2021-11-12T13:48:59.9999999')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "python3.7/site-packages/isodate/isodatetime.py", line 56, in parse_datetime
    tmptime = parse_time(timestring)
  File "python3.7/site-packages/isodate/isotime.py", line 134, in parse_time
    tzinfo)
ValueError: second must be in 0..59

Verison:

$ pip show isodate
Name: isodate
Version: 0.6.0
<snip>

• Make parse_datetime raise ISO8601Error if time designator 'T' is missing as before it would raise a ValueError that was hard to interpret.
• Alter test_parse for test_datetime to check that bad inputs raise an ISO8601 error. The other tests did this, but test_datetime didn't.
• Add test case where the 'T' time designator is missing from input datetime strings.

Using python3.8, with -Werror

>>> import datetime
>>> import isodate
>>> datetime.datetime.now() + isodate.parse_duration("P5Y")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/.tox/py38-std-sha256/lib/python3.8/site-packages/isodate/duration.py", line 183, in __add__
    newdt = other.replace(year=newyear, month=newmonth, day=newday)
DeprecationWarning: an integer is required (got type decimal.Decimal).  Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.

It looks like casting to int explicitly would solve the warning, something like:

ewdt = other.replace(year=int(newyear), month=int(newmonth), day=newday)

According to the release notes: https://docs.python.org/3.8/whatsnew/3.8.html

Many builtin and extension functions that take integer arguments will now emit a deprecation warning for Decimals, Fractions and any other objects that can be converted to integers only with a loss (e.g. that have the __int__() method but do not have the __index__() method). In future version they will be errors. (Contributed by Serhiy Storchaka in bpo-36048.)

Changes:

1. move license to Project's root
2. add a missing sentence from 2-clause license 3-clause license ("BSD License 2.0", "Revised BSD License", "New BSD License", or "Modified BSD License"): (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Issues:

1. https://github.com/gweis/isodate/issues/47

Please provide a proper LICENSE | COPYING | etc file, so it's clear under which license this project is.

(e.g: it mentions it's BSD, but there are more than 1 BSD license: BSD-2-Clause, BSD-3-Clause, BSD-4-Clause, and many more as specified in SPDX).

Adding a proper file, would allow packagers to integrate this project into linux-distros easier, so please do consider adding this and pushing a release with it.

I'm working on my calendar-cli.

A calendar event typically spans a time interval, and ISO 8601 does specify three standard ways of writing a time interval (according to wikipedia. I've sort of invented my own way of writing time intervals, but I thought it would be a good idea to support the standard as well. Actually doing the parsing of ISO time intervals is however out of the scope of calendar-cli, and I was expecting someone else had already written the code for it. Using a popular search engine, I found the isodate library - but apparently, it does not support parsing time intervals.

Is it on the roadmap? Eventually, if I would do the work myself, would someone assist me with design review, code review and merging? (I can't give any commitments on time frame for this one, right now I have lots of available time by the computer, but it may be years until next time).

Is that intentional or just a blunder? Tests should just be available to developers and run by the pipeline, I see no reason to distribute them to users. Other projects do not distribute them.

From https://github.com/gweis/isodate/pull/64:

A datetime.timedelta(days=1) is defined as exactly 24 hours, whereas ISO 8601 defines "P1D" as a calendar day, whose exact duration depends on its positioning in a calendar. For example, for the Europe/Amsterdam timezone (which happens to be my timezone), daylight saving time will start on March 28th 2021, which means March 28th in my calendar has 23 hours.

from datetime import timedelta
from isodate import duration_isoformat

print(duration_isoformat(timedelta(hours=24)))  # Outcome: P1D Expected: PT24H

If you'd like, I could try my hand at a PR, starting with introducing a new self.days attribute to express days as a nominal duration in the Duration class. I believe this issue also touches parse_duration.

Please let me know if this makes sense.

Hello,

I found that on some value of string , parse_date do not raise an Exception where it should. As i am using it in json hook it is problematique.

Example:

isodate.parse_date("16.263772,-61.2329") datetime.date(1601, 1, 1)

isodate.parse_date("100.263772,-61.2329") datetime.date(1001, 1, 1)

it does the same for any two (or more) digits number in before "."

Whereas date.fromisoformat do raise an error on those values.

I don't know if you will considere that as an issue.

Regards.