On Wed, Jan 5, 2011 at 6:12 PM, Guido van Rossum <gu...@python.org> wrote: .. > If they both impose some arbitrary limits, it would be easier for > users to remember the limits if they were the same for both modules. > Unfortunately, that is not possible on 32-bit systems where range supported by say time.ctime() is limited by the range of time_t.
> (In fact datetime.strftime() is currently limited by what > time.strftime() can handle -- more linkage.) > Not really. There is a patch at http://bugs.python.org/issue1777412 that removes this limit for datetime.strftime. There is an issue for pure python implementation that does depend on time.strftime(), but that can be addressed in several ways including ignoring it until time modules is fixed. .. >> Furthermore, >> this thread started with me arguing that year > 9999 should raise >> ValueError and if we wanted to restrict time module functions to >> datetime-supported year range, that would be the right thing to do. > > I'd be fine with a ValueError too, if that's what it takes to align > the two modules better. > Do you want to *add* year range checks to say time.localtime(t) so that it would not produce time tuple with out of range year? IMO, range checks are justified when they allow simpler implementation. As far as users are concerned, I don't think anyone would care about precise limits if they are wider than [1000 - 9999]. .. >> This said, I would be perfectly happy with just changing y >= 1900 to >> y >= 1000. Doing so will spare us from making a choice between >> '0012', '12' and ' 12' in time.asctime(). Time-series that extend >> back to 19th century are not unheard of and in many places modern >> calendar was already in use back then. Anything prior to year 1000 >> would certainly require a custom calendar module anyways. > > Yeah, but datetime takes a position here (arbitrarily extending the > Gregorian calendar all the way back to the year 1, and forward to the > year 9999). I'd be happiest if time took the same position. Doesn't it already? On my system, $ cal 9 1752 September 1752 Su Mo Tu We Th Fr Sa 1 2 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 but >>> (datetime(1752, 9, 2) - datetime(1970,1,1))//timedelta(0, 1) -6858259200 >>> time.gmtime(-6858259200)[:3] (1752, 9, 2) >>> datetime(1752, 9, 2).weekday() 5 >>> time.gmtime(-6858259200).tm_wday 5 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
