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 -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/K6I7QASU6ICNB4HD4MVHS3EBM4LRMBLS/ Code of Conduct: http://python.org/psf/codeofconduct/
