Richard Damon writes: > One issue with allowing Months here is then suddenly an interval > becomes dependent on when it is, so needs to be keep in a complex > form, as a month (and year) are variable length time units.
This is the paradigmatic reason why I don't want this in the stdlib. There's an irreducible ambiguity between what humans mean by "a month later" and what timedelta can deal with natively. But if it's going to be in the standard library, it should be a standard protocol. Note that hours have the same problem in jurisdictions that observe daylight savings time, and minutes have the same problem because of leap seconds. Weeks have a different problem (or ambiguity): suppose "1 week later" falls on a holiday? So, "consenting adults." The documentation can warn about these issues. You could also add a flag to accept years and months (and hours and minutes? ;-). But does something that needs such a flag belong in the stdlib? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K6I7QASU6ICNB4HD4MVHS3EBM4LRMBLS/ Code of Conduct: http://python.org/psf/codeofconduct/
