Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Month/year support #7

Open
jd opened this issue Oct 3, 2014 · 4 comments
Open

Month/year support #7

jd opened this issue Oct 3, 2014 · 4 comments

Comments

@jd
Copy link
Contributor

jd commented Oct 3, 2014

I see that its commented in the code, any reason for that?

@wroberts
Copy link
Owner

wroberts commented Nov 9, 2014

Months and years are periods of time directly related to the calendar; they could be included in pytimeparse, but only relative to a particular date (such as the current system time). There's also complications such as leap-years and leap-seconds. For the moment, I chose to only include time expressions which correspond to a fixed length of time.

minutes, hours, days: http://tools.ietf.org/html/rfc3339#section-2
weeks: http://www.tondering.dk/claus/cal/week.php#weeklengths

@jaraco
Copy link

jaraco commented Aug 18, 2017

There are use-cases where years/months support is useful even if not following a calendar, using nominal fixed lengths of time for each.

Consider the case where a user specifies an interval for expiration. For example, this cookie is good for "1 month" or delete all records older than "3 years". In these cases, being able to compare a timestamp or datetime against (now - interval) is useful, even if it's not going to be the same time on a wall clock or same day on the calendar.

For that reason, I've added months and years support to tempora's parse_timedelta function.

It would be useful in these cases if pytimeparse supported parsing months and years, either with a caution in the docs about what that means or even a UserWarning that an implementer may choose to suppress to acknowledge the potential pitfalls.

@jhtitor
Copy link

jhtitor commented Apr 1, 2018

+1. This would be extremely useful for reasons @jaraco listed.

Had to fork pytimeparse just for that little uncomment. Please give this issue another consideration.

@Toldry
Copy link

Toldry commented Nov 13, 2020

@wroberts Could you perhaps add a flag to the module that enables using months and years that users must explicitly set in order for those functions to work?

e.g.

import pytimeparse
pytimeparse.timeparse.timeparse('3 months') # None
pytimeparse.timeparse.enable_imprecise_months_and_years()
pytimeparse.timeparse.timeparse('3 months') # 7884000

You could use the average length of a month (30.42 days) and the average length of a year (365.25 days) to make it slightly more precise for general usage.

It is worth noting that that is what wolframalpha.com does:

https://www.wolframalpha.com/input/?i=1+month+to+seconds

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants