Commit Graph

103 Commits

Author SHA1 Message Date
Tim Peters 371935fc06 All over: changed comments to reflect pickling is straightforward now,
not the maze it was.
2003-02-01 01:52:50 +00:00
Tim Peters 8a60c2238b delta_setstate(): This waS no longer referenced, so nukeit.
delta_reduce():  Simplified.
2003-02-01 01:47:29 +00:00
Tim Peters 506be287aa The various datetime object __setstate__() methods are no longer public
(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.
2003-01-31 22:27:17 +00:00
Tim Peters abc7cd27ff Backward branches are disgusting, at least when a forward branch
is just as easy.
2003-01-31 01:37:35 +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 8bb5ad2e56 Updated the astimezone() proof to recover from all the last week's
changes (and there were a lot of relevant changes!).
2003-01-24 02:44:45 +00:00
Neal Norwitz 2fbe5378f9 Fix typo 2003-01-23 21:09:05 +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 b1049e8eca fromutc(): Repair incorrect failure return, as noted by NealN. Thanks! 2003-01-23 17:20:36 +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 a032d2eb7f Minor fiddling to make the next part easier. Introduced an internal
HASTZINFO() macro.
2003-01-11 00:15:54 +00:00
Neal Norwitz 8e914d9a1d Get rid of compiler warnings 2003-01-10 15:29:16 +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 33e0f383d4 Removed more now-pointless pickle code. 2003-01-10 02:05:14 +00:00
Tim Peters 7d4b315cca Deleted pickle/unpickle code for the old datetime and time classes -- it's
unreachable now.
2003-01-08 20:51:36 +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
Jack Jansen b8941f2dbe Added a couple of casts to make this compile with CodeWarrior. 2003-01-08 16:28:45 +00:00
Tim Peters 75a6e3bd1a datetime_from_timet_and_us(): ignore leap seconds if the platform
localtime()/gmtime() insists on delivering them, + associated doc
changes.

Redid the docs for datetimtez.astimezone().
2003-01-04 18:17:36 +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
Neal Norwitz 506a224688 Fix compiler warning 2003-01-04 01:02:25 +00:00
Tim Peters 4fede1a36b Completed astimezone()'s correctness proof. This also proves we can get
the desired compromise behavior during the "problem hour" when DST ends
cheaply (but I haven't yet implemented that).
2003-01-04 00:26:59 +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 c5dc4da125 The astimezone() correctness proof endured much pain to prove what
turned out to be 3 special cases of a single more-general result.
Proving the latter instead is a real simplification.
2003-01-02 17:55:03 +00:00
Tim Peters 5d644dd25a SF bug 661086: datetime.today() truncates microseconds.
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.
2003-01-02 16:32:54 +00:00
Tim Peters c3bb26a099 Completed astimezone's correctness proof. That doesn't mean it's
correct by your lights, it means that-- barring coding errors --it
implements what it intended to implement.
2003-01-02 03:14:59 +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 b5a16f3375 datetimetz_astimezone(): Speed optimizations -- although I'd rather
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.
2003-01-01 04:48:01 +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 e39a80c362 Bite the bullet on all the indirect timetz and datetimetz tzinfo methods:
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).
2002-12-30 21:28:52 +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 8702d5f33f And put back a little code duplication, in the form of asserts. 2002-12-27 02:26:16 +00:00
Tim Peters 00237037ae Squash recently-introduced code duplication. 2002-12-27 02:21:51 +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 80475bb4d2 Implemented datetime.astimezone() and datetimetz.astimezone(). 2002-12-25 07:40:55 +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 2736285035 call_utc_tzinfo_method(): Got rid of the label and the gotos. 2002-12-23 16:17:39 +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 83b85f1d6c Python's strftime implementation does strange things with the year,
such that the datetime tests failed if the envar PYTHON2K was set.
This is an utter mess, and the datetime module's strftime functions
inherit it.  I suspect that, regardless of the PYTHON2K setting, and
regardless of platform limitations, the datetime strftime wrappers
will end up delivering nonsense results (or bogus exceptions) for
any year before 1900.  I should probably just refuse to accept years
earlier than that -- else we'll have to implement strftime() by hand.
2002-12-22 20:34:46 +00:00
Tim Peters 14b6941197 classify_object(): Renamed more meaningfully, to classify_utcoffset().
Also changed logic so that instances of user-defined subclasses of date,
time, and datetime are called OFFSET_NAIVE instead of OFFSET_UNKNOWN.
2002-12-22 18:10:22 +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 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
Neal Norwitz dfb8086760 Fix another long vs int mismatch. test_datetime now passes on alpha 2002-12-19 02:30:56 +00:00
Tim Peters 0b0f41cf1f Fixed typo in string. 2002-12-19 01:44:38 +00:00
Neal Norwitz c296c63c73 Fix crash on alphas due to mismatch between 'l' format and int variables. 2002-12-19 00:42:03 +00:00
Tim Peters ba873472d2 delta_str(): Purged last uses of sprintf (in favor of PyOS_snprintf). 2002-12-18 20:19:21 +00:00
Jack Jansen 51cd8a2d24 "time_second" is apparently a #define on MacOSX. Renamed the (static)
routine to py_time_second.
2002-12-17 20:57:24 +00:00
Guido van Rossum bd43e9195b Fix GCC warnings. It turns out two out of three pointed to real bugs! 2002-12-16 20:34:55 +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