bolsote / isoduration Goto Github PK

Once durations are properly parsed and arithmetic operations with them implemented, the next step would be to support ISO 8601 repeating intervals. These would be string such as this one:

R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M

This means we repeat the interval P1Y2M10DT2H30M 5 times, starting at 2008-03-01T13:00:00Z.

Recurring intervals are described in great detail in the standard ISO 8601, part 1.

I just want to let you know that Python3.12 newly triggers following warning:

================================================== warnings summary ===================================================
../../../../../../../usr/lib/python3.12/site-packages/dateutil/tz/tz.py:37
  /usr/lib/python3.12/site-packages/dateutil/tz/tz.py:37: DeprecationWarning: datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.fromtimestamp(timestamp, datetime.UTC).
    EPOCH = datetime.datetime.utcfromtimestamp(0)

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
=========================================== 263 passed, 1 warning in 3.63s ============================================
>>> Completed testing dev-python/isoduration-20.11.0-r1

Right now, we have a fairly relaxed development requirements file. We should really pin all those versions, so we have a consistent environment everywhere. A pip-tools-based approach seems appropriate.

Hi! (Thanks for the library).

I believe the below isn't valid under the spec:

isoduration.parse_duration("P1")

which should be invalid, as it has no unit, but instead returns:

Duration(DateDuration(years=Decimal('0'), months=Decimal('0'), days=Decimal('0'), weeks=Decimal('0')), TimeDuration(hours=Decimal('0'), minutes=Decimal('0'), seconds=Decimal('0')))

#21 is possibly related.

We should create some basic documentation covering the most fundamental aspects of the library. We could start with:

• The Duration type and what it provides.
• str <-> Duration conversions (parsing/formatting).
• Exception hierarchy.
• How the test suite is organised.

When running pip install isoduration==20.11.0 or pip install isoduration
I get the following error:

Could not find a version that satisfies the requirement isoduration (from versions: )
No matching distribution found for isoduration

This happens to me in multiple environments

I was experimenting with the alternative duration format, and discovered some weird behavior:

>>> # Silently ignores alternate format when time is not provided
>>> isoduration.parse_duration('P0000-01-00')
Duration(DateDuration(years=Decimal('0'), months=Decimal('0'), days=Decimal('0'), weeks=Decimal('0')), TimeDuration(hours=Decimal('0'), minutes=Decimal('0'), seconds=Decimal('0')))
>>> # Doesn't handle alternate format duration with any of year/month/day being zero
>>> isoduration.parse_duration('P0000-00-00T00:00')
isoduration.parser.exceptions.UnparseableValue: Value could not be parsed as datetime: 0000-00-00T00:00
>>> # Ignores trailing numbers
>>> isoduration.parse_duration('P1MT1')
Duration(DateDuration(years=Decimal('0'), months=Decimal('1'), days=Decimal('0'), weeks=Decimal('0')), TimeDuration(hours=Decimal('0'), minutes=Decimal('0'), seconds=Decimal('0')))
>>> # Alternative format duration parsing accepts to many formats (e.g. YYYY-DDD)
>>> isoduration.parse_duration("P2020-123T00:00")
Duration(DateDuration(years=2020, months=5, days=2, weeks=Decimal('0')), TimeDuration(hours=0, minutes=0, seconds=0))
>>> # (note that this format causes the length in years to affect the number of days)
>>> isoduration.parse_duration("P2021-123T00:00")
Duration(DateDuration(years=2020, months=5, days=2, weeks=Decimal('0')), TimeDuration(hours=0, minutes=0, seconds=0))

No code changes should be required, just adding the new version to the testing support matrices.

Given the way things seem to be going, it makes sense to centralise tool configuration in a pyproject.toml file.

Hi,
I want to know is there any specific reason behind not bundling tests in released tarball?

Parts of the test suite are heavily data-driven. This means the parametrisation is considerably larger than the test body itself. We should consider something along the lines of what we did for the UK post code parser test suite, to make them easier to read.

When 0.5 is used in a value, it ends up as 0.5 in the DateDuration but appears to actually increment a datetime by 1. This behaviour also seems to apply to YMD and HMS but W seems to work in an incomplete way.

from datetime import datetime
from isoduration import parse_duration
datetime(2023, 1, 1) + parse_duration('P0.5M')
# datetime.datetime(2023, 2, 1, 0, 0)
parse_duration('P0.5M')
# Duration(DateDuration(years=Decimal('0'), months=Decimal('0.5'), days=Decimal('0'), weeks=Decimal('0')), TimeDuration(hours=Decimal('0'), minutes=Decimal('0'), seconds=Decimal('0')))

This prevents equality checks with different objects than other Duration objects.
Also should not be doing this in __add__, __sub__ or __rsub__ either.

See https://docs.python.org/3.11/library/constants.html#NotImplemented

In tests/test_benchmark.py, the function isoduration.parse_duration is imported, but named isodate_parse_duration. Subsequently, it is used in test_isodate, whereas isodate.parse_duration is used for test_isoduration. I therefore wonder whether your benchmark results are correctly interpreted?

Our benchmarks show we are indeed faster.

Is the difference significant?

Of particular interest would be section 5, «Repeat rules for recurring time intervals».

Thanks to the ground work performed for #5 it is now possible to support microsecond-level precision for addition.

Is this a bug?

>>> from isoduration import parse_duration
>>> from datetime import datetime
>>> now = datetime.now()
>>> d1 = parse_duration('P4W')
>>> d2 = parse_duration('P28D')
>>> d1 == d2
False
>>> now + d1 == now + d2
True
>>> now + d1 - now == now + d2 - now
True

Given one of the main motivations of this library was to improve the approach taken by isodate, we should trawl their issue tracker, and make sure we actually solve the most important problems found there.

We currently support decimal points at any point in the duration. In principle, this should only be allowed in the smallest value.

As a side effect, this would make it easier to properly manipulate the milliseconds part of the datetime in arithmetic operations.