On 8/23/20 7:21 AM, Stephen J. Turnbull wrote: > 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?
You get around leap seconds by just using the right time base, if you use UT1 or TAI then there are no leap seconds, so no problem there. Similarly for Daylight Savings Time, that is only an issue if you are in a frame that changes, if you define you time as a uniform frame (like GMT) then there is no DST to worry about (only when you convert your 'universal time measure' to a 'Local Clock Time' do you need to worry about that. As for holidays, why do holidays matter for time. A week after Dec 18th is Dec 25th, even if much of the world treats that day as differently. Now, if you want to deal with 'Work Weeks' or 'Work Days' then you need something more complicated, just like we had with months. -- Richard Damon _______________________________________________ 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/M32JGMFHN7CLT3JRZ2YC4URANRKS2GGO/ Code of Conduct: http://python.org/psf/codeofconduct/
