Commit Graph

74 Commits

Author SHA1 Message Date
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
Tim Peters b92bb71be8 Added test to ensure that non-string result from dst() raises TypeError. 2002-12-21 17:44:07 +00:00
Tim Peters fb8472c79c Changes sufficient so that pickles written by the Python implementation
can be read by the C implementation.  I don't really understand this.
2002-12-21 05:04:42 +00:00
Tim Peters 328fff7214 format_utcoffset(): The natural type of the buflen arg is size_t, so
used that.

wrap_strftime():  Removed the most irritating uses of buf.

TestDate.test_ordinal_conversions():  The C implementation is fast enough
that we can afford to check the endpoints of every year.  Also added
tm_yday tests at the endpoints.
2002-12-20 01:31:27 +00:00
Tim Peters cfd4a8b639 Made this a little more compatible w/ the sandbox version, which is
still needed to test the Python implementatino.
2002-12-16 21:12:37 +00:00
Tim Peters 2a799bf77a datetime escapes the sandbox. The Windows build is all set. I leave it
to others to argue about how to build it on other platforms (on Windows
it's in its own DLL).
2002-12-16 20:18:38 +00:00