Commit Graph

55 Commits

Author SHA1 Message Date
Georg Brandl 4ddfcd3b60 Bug #1556784: allow format strings longer than 127 characters in
datetime's strftime function.
2006-09-30 11:17:34 +00:00
Georg Brandl 6d78a582ec Bug #1478429: make datetime.datetime.fromtimestamp accept every float,
possibly "rounding up" to the next whole second.
2006-04-28 19:09:24 +00:00
Neal Norwitz d5b0c9b87e Fix problem spotted by Coverity that occurs if tzinfo.tzname().replace()
returns a non-string when converting %Z.

Will backport.
2006-03-20 01:58:39 +00:00
Armin Rigo f4afb21526 similar to SF bug 847019: a quick check in the time() constructor, which
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.
2005-11-07 07:15:48 +00:00
Guido van Rossum 5a8a03784e Use descriptors. 2005-01-16 00:25:31 +00:00
Skip Montanaro 0af3ade6aa Add strptime() constructor to datetime class. Thanks to Josh Spoerri for
the changes.
2005-01-13 04:12:31 +00:00
Tim Peters 528ca53b74 SF bug #1028306: date-datetime comparison
Treat comparing a date to a datetime like a mixed-type comparison.
2004-09-16 01:30:50 +00:00
Tim Peters 1b6f7a9057 Bug 975996: Add _PyTime_DoubleToTimet to C API
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.
2004-06-20 02:50:16 +00:00
Tim Peters 604c013ef2 SF 952807: Unpickling pickled instances of subclasses of datetime.date,
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.
2004-06-07 23:04:33 +00:00
Tim Peters 3f60629242 SF bug 847019 datetime.datetime initialization needs more strict checking
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.
2004-03-21 23:38:41 +00:00
Raymond Hettinger f69d9f6818 SF bug #761337: datetime.strftime fails on trivial format string
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.
2003-06-27 08:14:17 +00:00
Tim Peters b0c854d6a7 datetime.timedelta is now subclassable in Python. The new test shows
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.
2003-05-17 15:57:00 +00:00
Tim Peters a98924a063 datetime.datetime and datetime.time can now be subclassed in Python. Brr. 2003-05-17 05:55:19 +00:00
Tim Peters eb1a496039 test_subclass_date(): Beefed this up, to check that new instance
attributes and methods work, that new arguments can be passed to the
constructor, and that inherited methods and attrs still work.  Added
XXX comments about what to do when datetime becomes usably subclassable
too (it's not yet).
2003-05-17 02:25:20 +00:00
Guido van Rossum 8b7a9a38c6 The date class is now properly subclassable. (SF bug #720908)
(This is only the tip of the iceberg; the time and datetime classes
need the same treatment.)
2003-04-14 22:01:58 +00:00
Tim Peters f2715e0764 Whitespace normalization. 2003-02-19 02:35:07 +00:00
Tim Peters 68124bb771 The Python implementation of datetime was changed in ways that no longer
tickle the 2.2.2 __cmp__ bug test_datetime used to tickle, so the
workarounds for that bug no longer make sense in the test suite (which I'm
still trying to keep as closely in synch as possible with Zope3's
version).
2003-02-08 03:46:31 +00:00
Tim Peters 07534a607b Comparison for timedelta, time, date and datetime objects: __eq__ and
__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().
2003-02-07 22:50:28 +00:00
Guido van Rossum 275666fd50 Merge the test part of the below checkin to the sandbox and Zope3, so
the tests will remain in sync:

"""
Tres discovered a weird bug when a datetime is pickled, caused by the
shadowing of __year, __month, __day and the use of proxies.

Here's a quick fix and a quick unit test.  I don't quite understand
why this wasn't caught by the pickling unit tests.
"""
2003-02-07 21:49:01 +00:00
Tim Peters 844076122e SF bug 680864: test_datetime fails for non-unix epoch
Apparently MAC OS 9 doesn't have POSIX-conforming timestamps.  A test
fails as a result, but at least for this specific test it's easy enough
to get the POSIX epoch out of it.
2003-02-06 16:42:14 +00:00
Tim Peters 35ad641b99 Build pickler_choices list in a lazier way. 2003-02-05 04:08:07 +00:00
Guido van Rossum 49992f9d25 cPickle now implements enough of protocol 2 to enable all
cross-pickling tests.
2003-02-03 01:32:33 +00:00
Tim Peters b57f8f02ba There's no good reason for datetime objects to expose __getstate__()
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!).
2003-02-01 02:54:15 +00:00
Tim Peters 96940c971c Changed the tests to stop using __setstate__(). __setstate__() no
longer needs to be public, and shoudn't be public because all datetime
objects are immutable.  The Python implementation has changed
accordingly, but still need to change the C implementation.
2003-01-31 21:55:33 +00:00
Guido van Rossum 177e41a117 Change the approach to pickling to use __reduce__ everywhere. Most
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.
2003-01-30 22:06:23 +00:00
Tim Peters 8d81a012ef date and datetime comparison: when we don't know how to
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.
2003-01-24 22:36:34 +00:00
Tim Peters 2a44a8d332 SF bug 660872: datetimetz constructors behave counterintuitively (2.3a1).
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.
2003-01-23 20:53:10 +00:00
Tim Peters 10cadce41e Reimplemented datetime.now() to be useful. 2003-01-23 19:58:02 +00:00
Tim Peters 52dcce24e2 Bringing the code and test suite into line with doc and NEWS changes
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).
2003-01-23 16:36:11 +00:00
Tim Peters 327098a613 New rule for tzinfo subclasses handling both standard and daylight time:
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.
2003-01-20 22:54:38 +00:00
Tim Peters a9bc168f95 Got rid of the internal datetimetz type. 2003-01-11 03:39:11 +00:00
Tim Peters 37f398282b Got rid of the timetz type entirely. This was a bit trickier than I
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.
2003-01-10 03:49:02 +00:00
Tim Peters 0bf60bd67f Utterly minimal changes to collapse datetimetz into datetime, and timetz
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.
2003-01-08 20:40:01 +00:00
Tim Peters adf642038e A new implementation of astimezone() that does what we agreed on in all
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>).
2003-01-04 06:03:15 +00:00
Tim Peters 397301eccb The tzinfo methods utcoffset() and dst() must return a timedelta object
(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.
2003-01-02 21:28:08 +00:00
Tim Peters 710fb1548a astimezone() internals: if utcoffset() returns a duration, complain if
dst() returns None (instead of treating that as 0).
2003-01-02 19:35:54 +00:00
Tim Peters f36151556f A quicker astimezone() implementation, rehabilitating an earlier
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.
2003-01-01 21:51:37 +00:00
Tim Peters 36087edc05 The failure of the last-second addition to the timezone coversion test is
understood now:  it can't work.  Added comments explaining why (it's "the
usual"-- unrepresentable hours in local time --but in a slightly different
guise).
2003-01-01 04:18:51 +00:00
Tim Peters 521fc15e62 A new, and much hairier, implementation of astimezone(), building on
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.
2002-12-31 17:36:56 +00:00
Tim Peters bad8ff089a A step on the way to making tzinfo classes writable by mortals: get rid
of the timetz case.  A tzinfo method will always see a datetimetz arg,
or None, now.  In the former case, it's still possible that it will get
a datetimetz argument belonging to a different timezone.  That will get
fixed next.
2002-12-30 20:52:32 +00:00
Tim Peters 31cc3156e7 Added tests that conversion to our own timezone is always an identity,
and that conversion to "timezone" None is the same as stripping the
tzinfo member.
2002-12-30 17:37:30 +00:00
Tim Peters 1024bf8364 Beefed up the timezone conversion test by adding a phony UTC zone that's
west of the US zones getting converted, and also by using Eastern "as if"
it were UTC (wrt Pacific), and vice versa.
2002-12-30 17:09:40 +00:00
Tim Peters 621818b318 A start at non-trivial (== DST-aware) tests of timezone conversion.
Guido has in mind an easier way for users to code this stuff, but the
only tests we have now are for fixed-offset tzinfo classes, and this
stuff is extremely delicate in the endcases (read the new test code
for why:  there are holes in time <wink>).
2002-12-29 23:44:49 +00:00
Tim Peters 60c76e4016 Make comparison and subtraction of aware objects ignore tzinfo if the
operands have identical tzinfo members (meaning object identity -- "is").
I misunderstood the intent here, reading wrong conclusion into
conflicting clues.
2002-12-27 00:41:11 +00:00
Tim Peters 4c0db788e2 Added tests to ensure that timetz comparison, and datetimetz
subtraction, work as documented.  In the Python implementation,
they weren't calling utcoffset() if both operands had the same
tzinfo object.  That's fine if it so happens that the shared
tzinfo object returns a fixed offset (independent of operand),
but can give wrong results if that's not so, and the latter
obtains in a tzinfo subclass instance trying to model both
standard and daylight times.  The C implementation was already
doing this "correctly", so we're just adding tests to verify it.
2002-12-26 05:01:19 +00:00
Tim Peters 80475bb4d2 Implemented datetime.astimezone() and datetimetz.astimezone(). 2002-12-25 07:40:55 +00:00
Tim Peters 6578dc925f Whitespace normalization. 2002-12-24 18:31:27 +00:00
Tim Peters 12bf339aea Implemented .replace() methods for date, datetime, datetimetz, time and
timetz.
2002-12-24 05:41:27 +00:00
Tim Peters d684415572 I give up: unless I write my own strftime by hand, datetime just can't
be trusted with years before 1900, so now we raise ValueError if a date or
datetime or datetimetz .strftime() method is called with a year before
1900.
2002-12-22 20:58:42 +00:00
Tim Peters 855fe88b24 Implemented a Wiki suggestion:
{timetz,datetimetz}.{utcoffset,dst}() now return a timedelta (or None)
instead of an int (or None).

tzinfo.{utcoffset,dst)() can now return a timedelta (or an int, or None).

Curiously, this was much easier to do in the C implementation than in the
Python implementation (which lives in the Zope3 code tree) -- the C code
already had lots of hair to extract C ints from offset objects, and used
C ints internally.
2002-12-22 03:43:39 +00:00