Add direct to timedelta conversion

[2br-2b]

Right now, if you enter 1 month, then convert it into a timedelta as such:

datetime.timedelta(seconds=parse('1 month'))

Then, if you add that timedelta to a datetime, the value will be incorrect in certain months, as per the readme:

For months and years, the library does not consider complications such as leap- years and leap-seconds. Instead, it assumes "30 days for a month" and "365 days for a year" as the basis for calculations with those units.

It would be helpful to have a convert to timedelta option to handle stuff like this.

[onegreyonewhite]

@2br-2b looks like an good idea. But a lot of work))

[2br-2b]

Looking at the library functions and such for timedelta, it appears it doesn't have support for months or years - a third-party library would need to be implemented (see this StackOverflow post).

Given that, if you're okay with it, I might just make a PR to add in a simple parse_to_datetime which uses the other parse method but automatically generates a timedelta object

If you're okay with it, I might add dateutil as a dependency to make an object to return a dateutil.relativedelta; I'd just need to look the source code a bit more to understand it.

[onegreyonewhite]

Looking at the library functions and such for timedelta, it appears it doesn't have support for months or years - a third-party library would need to be implemented (see this StackOverflow post).

Given that, if you're okay with it, I might just make a PR to add in a simple parse_to_datetime which uses the other parse method but automatically generates a timedelta object

If you're okay with it, I might add dateutil as a dependency to make an object to return a dateutil.relativedelta; I'd just need to look the source code a bit more to understand it.

Good👍 But I think it would be better to rewrite logic to timedelta/relativedelta by default and convert output to seconds (backward capability) by argument. This changes will make code more clear and supportable.

I'm going to do this refactoring at next week or early (if I have time). You can review my PR.

[2br-2b]

Cool. The only problem I can think of is a drop in efficiency, but I don't think it'll be that bad (I hope).

Just a note: seems to be related to wroberts#11, wroberts#7, and wroberts#26 .

[onegreyonewhite]

Cool. The only problem I can think of is a drop in efficiency, but I don't think it'll be that bad (I hope).

Often, I check performance before release new features. If this feature breaks speed more then I can tolerate, then I make it separately.