On Fri, Sep 4, 2015 at 2:38 PM, Chris Barker <[email protected]> wrote:
> On Fri, Sep 4, 2015 at 11:19 AM, Carl Meyer <[email protected]> wrote: > >> On 09/04/2015 12:11 PM, Alexander Belopolsky wrote: >> > Keep in mind that the standard library should not only support "casual >> > users", but also those who will write a "period >> > recurrence library" for those "casual users." This is where classic >> > arithmetic is indispensable. >> > > I dont get that at all -- a Period recurrence lib needs to know all sorts > of stuff about the timezone, and other things, like days of the week. And > it needs to be able to do "timeline arithmetic", but it would presumable be > able to remove and tack back on a tzinfo object all on it's own -- i.e. so > the arithmetic it wants. > Let me try again. In my view, datetime class is a fancy way to encode 315537897600000000 integers: >>> 1 + (datetime.max - datetime.min) // datetime.resolution 315537897600000000 A timedelta class is a slightly less fancy way to encode some other 172799999913600000000 integers. The *natural* arithmetic on datetime and timedelta objects stems from the bijection between them and long integers. >>> t = datetime.now() >>> i = (t - datetime.min) // datetime.resolution >>> t == datetime.min + i * datetime.resolution True >>> d = timedelta(0, random()) >>> j = (d - timedelta.min) // timedelta.resolution >>> d == timedelta.min + j * timedelta.resolution True The "arithmetic" that datetime module implements is an efficient way to do addition and subtraction of datetime/timedelta objects without an explicit round trip to long integers (even though at the implementation level a round trip may take place). This arithmetic forms the basis for anything that you may want to do with datetimes: compute the number of business days in a year, compute the number of seconds in a century with or without the leap seconds, compute the angle in radians between the long hand and short hand of the Big Ben at 17:45:33.01 New York time. Timeline arithmetic is one of the simpler applications of the *natural* arithmetic provided by the datetime module: the timeline difference between t1 and t2 (assuming t1.tzinfo is t2.tzinfo) is just (t1 - t1.utcoffset()) - (t2 - t2.utcoffset()). Since "naive" difference between t1 and t2 that don't share tzinfo does not make sense, it was defined as a timeline difference. I think that was a mistake. I believe both Tim and Guido expressed a similar sentiment at various times. If datetime was designed today, t1 - t2 where t1.tzinfo is not t2.tzinfo would be an error and the user would have to choose between t1 - t2.astimezone(t1.tzinfo), t1.astimezone(t2.tzinfo) - t2 or t1.astimezone(utc) - t2.astimezone(utc) depending on the application need and with a full understanding that these three expressions can produce different results.
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
