summaryrefslogtreecommitdiffstats
path: root/Modules/datetimemodule.c
Commit message (Collapse)AuthorAgeFilesLines
* Bug #1478429: make datetime.datetime.fromtimestamp accept every float,Georg Brandl2006-04-281-0/+7
| | | | possibly "rounding up" to the next whole second.
* C++ compiler cleanup: "typename" is a C++ keywordSkip Montanaro2006-04-181-11/+11
|
* Coverity-found bug: datetime_strptime() failed to check for NULL return fromThomas Wouters2006-04-141-0/+4
| | | | | | PySequence_GetItem of the time.strptime() result. Not a high probability bug, but not inconceivable either, considering people can provide their own 'time' module.
* Fix problem spotted by Coverity that occurs if tzinfo.tzname().replace()Neal Norwitz2006-03-201-4/+9
| | | | | | returns a non-string when converting %Z. Will backport.
* More unconsting.Martin v. Löwis2006-02-271-11/+11
|
* Remove two instances of trailing commas. Resolves patch #1209781.Georg Brandl2006-02-191-1/+1
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-2/+2
|
* Check return result from Py_InitModule*(). This API can fail.Neal Norwitz2006-01-191-0/+2
| | | | Probably should be backported.
* Add const to several API functions that take char *.Jeremy Hylton2005-12-101-16/+16
| | | | | | | | | | | | | | | | | | | In C++, it's an error to pass a string literal to a char* function without a const_cast(). Rather than require every C++ extension module to put a cast around string literals, fix the API to state the const-ness. I focused on parts of the API where people usually pass literals: PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type slots, etc. Predictably, there were a large set of functions that needed to be fixed as a result of these changes. The most pervasive change was to make the keyword args list passed to PyArg_ParseTupleAndKewords() to be a const char *kwlist[]. One cast was required as a result of the changes: A type object mallocs the memory for its tp_doc slot and later frees it. PyTypeObject says that tp_doc is const char *; but if the type was created by type_new(), we know it is safe to cast to char *.
* similar to SF bug 847019: a quick check in the time() constructor, whichArmin Rigo2005-11-071-1/+2
| | | | | | accepts strings only for unpickling reasons. This check prevents the honest mistake of passing a string like '2:59.0' to time() and getting an insane object.
* Add strptime() constructor to datetime class. Thanks to Josh Spoerri forSkip Montanaro2005-01-131-0/+45
| | | | the changes.
* Bug #1087216: datetime module documentation missing critical detailRaymond Hettinger2004-12-191-3/+9
|
* SF bug #1028306: date-datetime comparisonTim Peters2004-09-161-1/+11
| | | | Treat comparing a date to a datetime like a mixed-type comparison.
* SF patch 876130: add C API to datetime module, from Anthony Tuininga.Tim Peters2004-06-201-0/+30
| | | | | | The LaTeX is untested (well, so is the new API, for that matter). Note that I also changed NULL to get spelled consistently in concrete.tex. If that was a wrong thing to do, Fred should yell at me.
* Bug 975996: Add _PyTime_DoubleToTimet to C APITim Peters2004-06-201-5/+15
| | | | | | | | | | | New include file timefuncs.h exports private API function _PyTime_DoubleToTimet() from timemodule.c. timemodule should export some other functions too (look for painful bits in datetimemodule.c). Added insane-argument checking to datetime's assorted fromtimestamp() and utcfromtimestamp() methods. Added insane-argument tests of these to test_datetime, and insane-argument tests for ctime(), localtime() and gmtime() to test_time.
* SF 952807: Unpickling pickled instances of subclasses of datetime.date,Tim Peters2004-06-071-6/+3
| | | | | | | datetime.datetime and datetime.time could yield insane objects. Thanks to Jiwon Seo for the fix. Bugfix candidate. I'll backport it to 2.3.
* SF bug 847019 datetime.datetime initialization needs more strict checkingTim Peters2004-03-211-2/+10
| | | | | | | | | It's possible to create insane datetime objects by using the constructor "backdoor" inserted for fast unpickling. Doing extensive range checking would eliminate the backdoor's purpose (speed), but at least a little checking can stop honest mistakes. Bugfix candidate.
* Have strftime() check its time tuple argument to make sure the tuple's valuesBrett Cannon2004-03-021-2/+2
| | | | | | | | | | are within proper boundaries as specified in the docs. This can break possible code (datetime module needed changing, for instance) that uses 0 for values that need to be greater 1 or greater (month, day, and day of year). Fixes bug #897625.
* Fix a bunch of typos in documentation, docstrings and comments.Walter Dörwald2003-10-201-2/+2
| | | | (From SF patch #810751)
* Simplify and speedup uses of Py_BuildValue():Raymond Hettinger2003-10-121-4/+4
| | | | | | * Py_BuildValue("(OOO)",a,b,c) --> PyTuple_Pack(3,a,b,c) * Py_BuildValue("()",a) --> PyTuple_New(0) * Py_BuildValue("O", a) --> Py_INCREF(a)
* SF bug #761337: datetime.strftime fails on trivial format stringRaymond Hettinger2003-06-271-1/+1
| | | | | | | | | | | | | | The interning of short strings violates the refcnt==1 assumption for _PyString_Resize(). A simple fix is to boost the initial value of "totalnew" by 1. Combined with an NULL argument to PyString_FromStringAndSize(), this assures that resulting format string is not interned. This will remain true even if the implementation of PyString_FromStringAndSize() changes because only the uninitialized strings that can be interned are those of zero length. Added a test case.
* Added more words about the abuse of the tp_alloc nitems argumentTim Peters2003-05-181-1/+12
| | | | perpetrated by the time and datetime classes.
* datetime.timedelta is now subclassable in Python. The new test showsTim Peters2003-05-171-165/+170
| | | | | | | | one good use: a subclass adding a method to express the duration as a number of hours (or minutes, or whatever else you want to add). The native breakdown into days+seconds+us is often clumsy. Incidentally moved a large chunk of object-initialization code closer to the top of the file, to avoid worse forward-reference trickery.
* datetime.datetime and datetime.time can now be subclassed in Python. Brr.Tim Peters2003-05-171-30/+46
|
* Turns out there wasn't a need to define tp_free for any of the types here.Tim Peters2003-05-161-4/+4
|
* Stopped using the old macro form of _PyObject_Del.Tim Peters2003-05-161-4/+4
|
* SF patch 731504: Typo in datetimemodule.c comment.Tim Peters2003-05-021-1/+1
| | | | s/isofomat/isoformat/, by Steven Taschuk.
* The date class is now properly subclassable. (SF bug #720908)Guido van Rossum2003-04-141-5/+8
| | | | | (This is only the tip of the iceberg; the time and datetime classes need the same treatment.)
* timedelta comparison and datetime addition: as the Python implementationTim Peters2003-02-081-4/+4
| | | | of datetime does, accept instances of subclasses too.
* Comparison for timedelta, time, date and datetime objects: __eq__ andTim Peters2003-02-071-38/+52
| | | | | | | | | | | | | | | | | __ne__ no longer complain if they don't know how to compare to the other thing. If no meaningful way to compare is known, saying "not equal" is sensible. This allows things like if adatetime in some_sequence: and somedict[adatetime] = whatever to work as expected even if some_sequence contains non-datetime objects, or somedict non-datetime keys, because they only call __eq__. It still complains (raises TypeError) for mixed-type comparisons in contexts that require a total ordering, such as list.sort(), use as a key in a BTree-based data structure, and cmp().
* Whitespace normalizationNeal Norwitz2003-02-041-1/+1
|
* New functions alloc_{time,datetime}. Got rid of all setstate-likeTim Peters2003-02-011-168/+123
| | | | | | | | | | functions. Reworked {time,datetime}_new() to do what their corresponding setstates used to do in their state-tuple-input paths, but directly, without constructing an object with throwaway state first. Tightened the "is this a state tuple input?" paths to check the presumed state string-length too, and to raise an exception if the optional second state element isn't a tzinfo instance (IOW, check these paths for type errors as carefully as the normal paths).
* There's no good reason for datetime objects to expose __getstate__()Tim Peters2003-02-011-52/+4
| | | | | | anymore either, so don't. This also allows to get rid of obscure code making __getnewargs__ identical to __getstate__ (hmm ... hope there wasn't more to this than I realize!).
* Removed all uses of the out-of-favor __safe_for_unpickling__ magicTim Peters2003-02-011-27/+0
| | | | attr, and copy_reg.safe_constructors.
* All over: changed comments to reflect pickling is straightforward now,Tim Peters2003-02-011-7/+5
| | | | not the maze it was.
* delta_setstate(): This waS no longer referenced, so nukeit.Tim Peters2003-02-011-38/+2
| | | | delta_reduce(): Simplified.
* The various datetime object __setstate__() methods are no longer publicTim Peters2003-01-311-116/+105
| | | | | | | | (pickling no longer needs them, and immutable objects shouldn't have visible __setstate__() methods regardless). Rearranged the code to put the internal setstate functions in the constructor sections. Repaired the timedelta reduce() method, which was still producing stuff that required a public timedelta.__setstate__() when unpickling.
* Backward branches are disgusting, at least when a forward branchTim Peters2003-01-311-6/+6
| | | | is just as easy.
* Change the approach to pickling to use __reduce__ everywhere. MostGuido van Rossum2003-01-301-242/+221
| | | | | | | classes have a __reduce__ that returns (self.__class__, self.__getstate__()). tzinfo.__reduce__() is a bit smarter, calling __getinitargs__ and __getstate__ if they exist, and falling back to __dict__ if it exists and isn't empty.
* date and datetime comparison: when we don't know how toTim Peters2003-01-241-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | compare against "the other" argument, we raise TypeError, in order to prevent comparison from falling back to the default (and worse than useless, in this case) comparison by object address. That's fine so far as it goes, but leaves no way for another date/datetime object to make itself comparable to our objects. For example, it leaves Marc-Andre no way to teach mxDateTime dates how to compare against Python dates. Discussion on Python-Dev raised a number of impractical ideas, and the simple one implemented here: when we don't know how to compare against "the other" argument, we raise TypeError *unless* the other object has a timetuple attr. In that case, we return NotImplemented instead, and Python will give the other object a shot at handling the comparison then. Note that comparisons of time and timedelta objects still suffer the original problem, though.
* Updated the astimezone() proof to recover from all the last week'sTim Peters2003-01-241-77/+94
| | | | changes (and there were a lot of relevant changes!).
* Fix typoNeal Norwitz2003-01-231-1/+1
|
* SF bug 660872: datetimetz constructors behave counterintuitively (2.3a1).Tim Peters2003-01-231-12/+20
| | | | | | This gives much the same treatment to datetime.fromtimestamp(stamp, tz) as the last batch of checkins gave to datetime.now(tz): do "the obvious" thing with the tz argument instead of a senseless thing.
* Reimplemented datetime.now() to be useful.Tim Peters2003-01-231-7/+17
|
* fromutc(): Repair incorrect failure return, as noted by NealN. Thanks!Tim Peters2003-01-231-1/+1
|
* Bringing the code and test suite into line with doc and NEWS changesTim Peters2003-01-231-92/+127
| | | | | | | | | | | | | | | | | | | | checked in two days agao: Refactoring of, and new rules for, dt.astimezone(tz). dt must be aware now, and tz.utcoffset() and tz.dst() must not return None. The old dt.astimezone(None) no longer works to change an aware datetime into a naive datetime; use dt.replace(tzinfo=None) instead. The tzinfo base class now supplies a new fromutc(self, dt) method, and datetime.astimezone(tz) invokes tz.fromutc(). The default implementation of fromutc() reproduces the same results as the old astimezone() implementation, but tzinfo subclasses can override fromutc() if the default implementation isn't strong enough to get the correct results in all cases (for example, this may be necessary if a tzinfo subclass models a time zone whose "standard offset" (wrt UTC) changed in some year(s), or in some variations of double-daylight time -- the creativity of time zone politics can't be captured in a single default implementation).
* New rule for tzinfo subclasses handling both standard and daylight time:Tim Peters2003-01-201-21/+3
| | | | | | | | | | | | When daylight time ends, an hour repeats on the local clock (for example, in US Eastern, the clock jumps from 1:59 back to 1:00 again). Times in the repeated hour are ambiguous. A tzinfo subclass that wants to play with astimezone() needs to treat times in the repeated hour as being standard time. astimezone() previously required that such times be treated as daylight time. There seems no killer argument either way, but Guido wants the standard-time version, and it does seem easier the new way to code both American (local-time based) and European (UTC-based) switch rules, and the astimezone() implementation is simpler.
* Got rid of the internal datetimetz type.Tim Peters2003-01-111-1004/+635
|
* Minor fiddling to make the next part easier. Introduced an internalTim Peters2003-01-111-17/+20
| | | | HASTZINFO() macro.
* Get rid of compiler warningsNeal Norwitz2003-01-101-2/+2
|
generated by cgit v0.12 at 2024-11-25 10:29:42 (GMT)