summaryrefslogtreecommitdiffstats
path: root/Modules/datetimemodule.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Completed astimezone's correctness proof. That doesn't mean it'sTim Peters2003-01-021-4/+51
| | | | | correct by your lights, it means that-- barring coding errors --it implements what it intended to implement.
* A quicker astimezone() implementation, rehabilitating an earlierTim Peters2003-01-011-65/+151
| | | | | | | | | | | | | | | | | | | suggestion from Guido, along with a formal correctness proof of the trickiest bit. The intricacy of the proof reveals how delicate this is, but also how robust the conclusion: correctness doesn't rely on dst() returning +- one hour (not all real time zones do!), it only relies on: 1. That dst() returns a (any) non-zero value if and only if daylight time is in effect. and 2. That the tzinfo subclass implements a consistent notion of time zone. The meaning of "consistent" was a hidden assumption, which is now an explicit requirement in the docs. Alas, it's an unverifiable (by the datetime implementation) requirement, but so it goes.
* datetimetz_astimezone(): Speed optimizations -- although I'd ratherTim Peters2003-01-011-32/+38
| | | | | | | | | find a more elegant algorithm (OTOH, the hairy new implementation allows user-written tzinfo classes to be elegant, so it's a big win even if astimezone() remains hairy). Darn! I've only got 10 minutes left to get falling-down drunk! I suppose I'll have to smoke crack instead now.
* A new, and much hairier, implementation of astimezone(), building onTim Peters2002-12-311-24/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | an idea from Guido. This restores that the datetime implementation never passes a datetime d to a tzinfo method unless d.tzinfo is the tzinfo instance whose method is being called. That in turn allows enormous simplifications in user-written tzinfo classes (see the Python sandbox US.py and EU.py for fully fleshed-out examples). d.astimezone(tz) also raises ValueError now if d lands in the one hour of the year that can't be expressed in tz (this can happen iff tz models both standard and daylight time). That it used to return a nonsense result always ate at me, and it turned out that it seemed impossible to force a consistent nonsense result under the new implementation (which doesn't know anything about how tzinfo classes implement their methods -- it can only infer properties indirectly). Guido doesn't like this -- expect it to change. New tests of conversion between adjacent DST-aware timezones don't pass yet, and are commented out. Running the datetime tests in a loop under a debug build leaks 9 references per test run, but I don't believe the datetime code is the cause (it didn't leak the last time I changed the C code, and the leak is the same if I disable all the tests that invoke the only function that changed here). I'll pursue that next.
* Bite the bullet on all the indirect timetz and datetimetz tzinfo methods:Tim Peters2002-12-301-14/+20
| | | | | | make the callers figure out the right tzinfo arguments to pass, instead of making the callees guess. The code is uglier this way, but it's less brittle (when the callee guesses, the caller can get surprised).