summaryrefslogtreecommitdiffstats
path: root/Modules/datetimemodule.c
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* Got rid of the timetz type entirely. This was a bit trickier than ITim Peters2003-01-101-476/+336
| | | | | | | hoped it would be, but not too bad. A test had to change: time.__setstate__() can no longer add a non-None tzinfo member to a time object that didn't already have one, since storage for a tzinfo member doesn't exist in that case.
* Removed more now-pointless pickle code.Tim Peters2003-01-101-93/+34
|
* Deleted pickle/unpickle code for the old datetime and time classes -- it'sTim Peters2003-01-081-160/+0
| | | | unreachable now.
* Utterly minimal changes to collapse datetimetz into datetime, and timetzTim Peters2003-01-081-17/+10
| | | | | | | | | into time. This is little more than *exporting* the datetimetz object under the name "datetime", and similarly for timetz. A good implementation of this change requires more work, but this is fully functional if you don't stare too hard at the internals (e.g., right now a type named "datetime" shows up as a base class of the type named "datetime"). The docs also need extensive revision, not part of this checkin.
* Added a couple of casts to make this compile with CodeWarrior.Jack Jansen2003-01-081-3/+3
|
* datetime_from_timet_and_us(): ignore leap seconds if the platformTim Peters2003-01-041-1/+10
| | | | | | | localtime()/gmtime() insists on delivering them, + associated doc changes. Redid the docs for datetimtez.astimezone().
* A new implementation of astimezone() that does what we agreed on in allTim Peters2003-01-041-41/+35
| | | | | | cases, plus even tougher tests of that. This implementation follows the correctness proof very closely, and should also be quicker (yes, I wrote the proof before the code, and the code proves the proof <wink>).
* Fix compiler warningNeal Norwitz2003-01-041-1/+1
|
* Completed astimezone()'s correctness proof. This also proves we can getTim Peters2003-01-041-4/+53
| | | | | the desired compromise behavior during the "problem hour" when DST ends cheaply (but I haven't yet implemented that).
* The tzinfo methods utcoffset() and dst() must return a timedelta objectTim Peters2003-01-021-22/+14
| | | | | | (or None) now. In 2.3a1 they could also return an int or long, but that was an unhelpfully redundant leftover from an earlier version wherein they couldn't return a timedelta. TOOWTDI.
* astimezone() internals: if utcoffset() returns a duration, complain ifTim Peters2003-01-021-1/+5
| | | | dst() returns None (instead of treating that as 0).
* The astimezone() correctness proof endured much pain to prove whatTim Peters2003-01-021-70/+43
| | | | | turned out to be 3 special cases of a single more-general result. Proving the latter instead is a real simplification.
* SF bug 661086: datetime.today() truncates microseconds.Tim Peters2003-01-021-7/+16
| | | | | | | | | | | | | | | | On Windows, it was very common to get microsecond values (out of .today() and .now()) of the form 480999, i.e. with three trailing nines. The platform precision is .001 seconds, and fp rounding errors account for the rest. Under the covers, that 480999 started life as the fractional part of a timestamp, like .4809999978. Rounding that times 1e6 cures the irritation. Confession: the platform precision isn't really .001 seconds. It's usually worse. What actually happens is that MS rounds a cruder value to a multiple of .001, and that suffers its own rounding errors. A tiny bit of refactoring added a new internal utility to round doubles.
generated by cgit v0.12 at 2024-09-29 15:41:22 (GMT)